egmontkob
commented
1 year ago Hello,
I'm not a Terminator developer, but I'm a former VTE developer who implemented rewrapping the contents on resize. (VTE is the terminal emulator widget used by Terminator and quite a few others.)
Increasing the font size is only slow if the previous number of columns no longer fit on the screen and the terminal has to become narrower (in terms of character columns). So, effectively we're talking about a resize operation rather than a font size change. As you have probably already guessed, resizing is slow because it has to go through the entire scrollback history and rewrap the lines according to the new width. The larger the scrollback, the longer it takes. And yes, as you've noticed, this is done synchronously, that is, no input is processed and the display isn't updated either during this time.
Rewrapping was implemented 10 years ago, and surprisingly, this is the first report I'm encountering that with giant scrollback it's slow, I expected complaints to arrive sooner. :)
Something that is less obvious:
Rewrapping is much faster for paragraphs (consecutive lines that wrap together) that consist purely of plain ASCII 32..126 characters; that is, no TABs, no non-English letters and other special symbols; and is even somewhat faster for giant portions of the data (hundreds of kilobytes) that are entirely of this nature. Moreover, having fewer or ideally no attribute changes at all (no colors, bold, etc.) can also speed things up. We're easily talking about a 5x overall speedup if all circumstances are ideal.
This is due to how the scrollback is stored internally. Without going into the details too much: When rewrapping, the text and attributes storage doesn't need to be modified, what needs to be updated is for each visual row an indexing directly into the text and attributes where this row's data begins. If a paragraph consists of ASCII 32..126 characters only (we keep track of this property) then we take a special faster code path: we immediately know which byte will belong to which new character cell, and we can perform the rewrapping (i.e. calculate the new indexes) without looking at the actual text. If there's anything fancier involved, i.e. either characters that are expressed as multi-byte UTF-8 sequences or characters that occupy multiple cells on the screen then we have to take the generic, slower code path: walk through the text, character by character, to find the new line beginnings. The text is stored on disk by splitting it into 64 kB chunks, then compressing and encrypting each chunk separately. If an entire chunk consists of only ASCII 32..126 characters then we even save the cost of reading it from disk, decrypting and decompressing.
I am right now pondering about various ways of coming up with other special cases that could be handled by a special, faster code path. Let's say, we could store the actual width of each line, and then we'd know upfront if a given paragraph will fit in a single line after rewrapping, this could save the cost of reading and processing its text character by character. Or it would be great if we could somehow have a faster branch for paragraphs that contain single-width glyphs only.
Could you help me please here? I'd like to understand the characteristics of your scrollback data, to know if you already benefit from some speedup of the special cases or not yet, and whether you'd benefit from the speedup of various rough ideas that I have currently.
What does your data look like? Is is typically in the ASCII 32..126 range, that is, plain English, and without the TAB character? Or do you frequently have TABs? Do you frequently have single-width non-ASCII characters (e.g. accented Latin characters, fancy quote signs, etc.)? How frequently do you estimate you have a character that's outside of the plain English ASCII 32..126 range? Do you frequently have double-width characters (such as CJK, emojis)? How frequently do you have attribute changes (color, bold, italic, underline etc.)?
How long are your paragraphs (logical lines)? Do they typically fit in a single visual line before the font incrase? And after? Or are they wrapped into maybe like 2-3-4 visual lines? Or even more? Or do you perhaps typically have extremely long paragraphs (let's say enormous auto-generated XML files with not a single newline within them, dumped to the terminal)?
You make a point that resizing should asynchronous, not blocking.
In an ideal world, yes. But the thing is: The rewrapping code is already quite complicated, and making it asynchronous sounds like a nightmare programming task that would make it at least a magnitude more complicated. Let me give you just a few reasons.
Assuming that the terminal is scrolled to its default bottom position, the code would have to immediately rewrap that, and then, while processing new input and updating the user interface, it would have to asynchronously rewrap the scrollback, and finally stitch the two together correctly.
The terminal is not necessarily scrolled there, though, it could be scrolled to let's say somewhere in the middle of the scrollback buffer. It would immediately need to rewrap the last several lines (in order to correctly process new incoming data and perform the terminal emulation there according to the new size) and also immediately rewrap the lines around the current viewport.
If the user scrolls, either in small steps (e.g. Shift+PageUp/Dn) or by large steps (dragging the scrollbar) then this new viewport should also be immediately rewrapped in order to display it (the background rewrapping task may or may not have reached this point yet).
It would have to handle correctly if a subsequent resize event (or many of them) arrives while background rewrapping is in progress.
It would have to handle correctly if newly processed data causes the contents to scroll, potentially almost as quickly, or maybe at an even faster rate than asynchronous rewrapping can be performed.
The latter two combined, we could quickly arrive at an intermittent situation where the scrollback is a mixture of not just two but many different terminal widths which needs to be tracked correctly and eventually wrapped to the same final width.
It would have to handle reasonably well that the scrollbar's position is not exact, it's only a rough estimate while background asynchronous rewrapping is being performed, since we can't know until the end of the entire operation how many lines there will be exactly and where exactly the currently displayed ones reside in that range.
All this should be combined with the fact that it's very hard to debug, very hard to track down any issue while developing. Due to the asynchronous nature itself, if a sequence of steps causes a crash (which is absolutely inevitable to happen many times during such a development process) then next time the same steps will likely complete just fine. It would often be very hard to reproduce and understand a crash that either the developer experiences or a user reports.
My very rough (and perhaps very wrong) estimate is that coding this up would take me perhaps the equivalent of 2-4 months of full time work, which would be mentally exhausting and would drive me crazy many times. The result would be a much more complicated code than the current one. And since that code has to live on, has to be maintained forever, I'm not sure if upstream would accept the change. The benefit it would bring isn't worth the effort, nor the resulting complexity.
Ideally, yes, I fully agree with you, resizing should be asynchronous. In practice, it's just absolutely not worth it.
I'll keep thinking about lowhanging fruit improvements that may (or may not, depending on your usage pattern) bring you noticeable speed improvements (while still remaining synchronous).
In the mean time, I also suggest you to reevalute your workflow and see if you really need this big of a scrollback buffer. Such amount of data cannot be processed by humans when it's first printed, cannot reasonably be examined by scrolling either, and the terminal's search facility probably isn't ideal either. Can't you live with a scrollback buffer of about 100,000 lines? Or maybe pipe your verbose apps' outputs to less? Or maybe even also automatically log each session in a file, using script, to be examined with more powerful tools if needed? Or how about making your apps significantly less verbose?
Yet another alternative: Even though VTE deprecated the non-rewrapping resize behavior, it hasn't been removed yet. However, Terminator removed the corresponding option in #303. You can patch your Terminator to bring it back and disable rewrapping (although in my opinion rewrapping is definitely worth the short wait).
Or maybe you can pick a single preferred font size and stick with that (maybe the bigger one straight from the beginning). Or use a desktop environment which does not confine the window into the display, rather allows it to stick out if the app requests a bigger size. Or, of course, just accept the occasional short wait.
Unfortunately, at this moment you can't have a giant scrollback, rewrapping on resize, and instantenous resizing experience all at the same time (my guess is that no terminal emulator out there offers this), you have to make a compromise somewhere, and this constraint is extremely unlikely to get eliminated any time in the foreseeable future.
0xFFFC0000
mattrose
Have a terminal with more than 1,000,000 lines of output. Increase the font size with ctrl++. It is going to block. This should be at least async. Not blocking.