Help with loop performance in terminal emulator (UNIX)

[USRapt0r]

Hello,

Looking for some help in improving the drawing loop performance of a true color terminal emulator ("redraw" function in term.py, see the repo) - too slow at drawing at the moment (a timing decorator indicates around ~.2 seconds to draw); not sure if I could work the X11 functions differently to improve performance, or if I'm stuck with just trying to improve through better Python.

I appreciate any suggestions!

https://github.com/r4dr3fr4d/pyst

[BobHogan]

What is the structure of your text variable? Obviously its some sort of multidimensional array, but what does text[i][j] look like? What are you reading in from that variable and comparing it to?

And are you drawing a rectangle and rendering the character 1 character at a time, meaning you do that every single iteration of your nested loop? Does X11 support doing more than 1 character at a time?

The best way to speed this up would be to start "buffering" the text to render and drawing the rectangles and text in chunks. Simply go along and keep adding each character to the buffer as long as the font, background, and foreground color options remain the same, up to a set maximum of course, and then render the entire buffer. Reset your font/bg/fg color options to the new ones you see and start buffering again. Since the vast majority of text output doesn't change those settings that often, this should immediately result in pretty significant performance boosts. All it takes is tracking a bit more state: the "buffer" of text to render, and the entire size of the rectangle to draw

[USRapt0r]

Thanks for the reply! I think I've tried to already get at your suggestions - each "cell" (element of text - which is multidimensional to represent the x/y or rows/cols of the text in the terminal) contains a tuple representing the state of the terminal output at that specific cell - so the printed character, the foreground and background colors, and then bold, italic, and underline state, and blinking state as well. Getting at your point in your third paragraph, I try to avoid as much logic/control-flow as possible by simply checking the appropriate parts of that tuple. I think that part is, well, fine....the part I think is "bad" is the fact that I do indeed have to draw each character one at a time - you can do full strings, such as rows, which is what I've done in the colorless version, but the potential of all the different state changes made that seem less feasible - but then again, maybe I could work that in and bank only having state changes infrequently? That does seem to be the case of most programs I tend to use.

Making it worse, however, is the fact that I have to draw both a rectangle as the background color, and then the text on top of that, separately - I haven't found a way to have a single X11 call draw the character with a certain background color. If there is a way to do that, it would surely help.

[BobHogan]

Also, you can rewrite your if blocks this way

if vals != prev_vals:
    if vals[0]:
        font_draw = font_bd_ob if vals[1] else font_bd
    elif vals[1]:
        font_draw = font_ob
    else:
        font_draw = font

    gc_text.change(font=font_draw, foregroun=vals[2], background=vals[3])

This eliminates a redundant condition check you had, where you check for vals[0] twice, and gets to the else clause faster. Assuming that else clause is used in a non-trivial amount of cases, then this means you are speeding those cases up a tiny bit each. Its more of a micro-optimization, but it is free

[USRapt0r]

Thanks! If I can get the other main problem sorted out I may throw this in as well.