GNOME Terminal Gets Text Rewrap On Resizing

[egmont]

This is fantastic! But I guess it has a performance impact, the terminal has to keep all the output in a buffer of some sort, and reprint it to the new size of the terminal. Before, the terminal could just render the output, and then throw the text strings away, right? Or have they always kept the actual strings in memory?

The terminal remembers a configurable number of lines, this is the scrollback buffer that you can access by Shift+PageUp or with the scrollbar. This has not changed (well, strictly speaking the implementation has changed a little but you shouldn't be able to notice it) and rewrapping doesn't have an impact at all as long as you don't resize the window.

Rewrapping occurs and has a performance impact the moment you resize. On my average laptop, rewrapping takes around 0.2 seconds with a scrollback buffer of 1 million lines. Most people use a scrollback buffer somewhere between 1000 and 10000 lines, hence the performance penalty is negligible. Gnome-terminal allows you to have infinite scrollback, if it grows beyond a few million lines and then you resize the terminal then it's going to be really slow. For this reason, we plan to make rewrapping configurable so you can turn it off if you prefer giant scrollback and want to resize quickly.

[egmont]

If the clean up of the code base resulted in the rewrap functionality the loss of transparency was a good sacrifice.

These two have nothing to do with each other.

As a matter of fact, it's not Gnome-terminal itself, but the underlying VTE component that added rewrapping, and the very same version of VTE (0.35) still supports transparency (although unfortunately marked as deprecated, and the corresponding checkbox was indeed removed from Gnome-terminal).

Pair up VTE 0.35 with Gnome-terminal 3.6 and you'll get both rewrapping and transparent background

[egmont]

I thought no rewrap is a deliberate design decision. And wow, why does even a lousy text editor have rewrap but gnome/kde consoles don't? They use a different/archaic toolkit to draw text or what?

It's not the drawing toolkit, it's the general concept. Text editors work on relatively small files (couple of megabytes maybe), files are linear stream of data with explicit newlines, and are fairly easy to handle. Terminals provide support for linearly printed text as well as absolute cursor positioning within the main canvas area (jumping anywhere, printing a few characters there, jumping again etc.), plus millions of other hairy tricks, it's not easy to reasonably define how this content needs to be rewrapped on a resize. Also, the amount of data (including the scrollback buffer) can easily be magnitudes larger than average text files.

[egmont]

rxvt has had this feature for years. It's one of those features you only miss when it's gone, and it's the primary reason I've been sticking with rxvt ever since.

I really do hope gnome-terminal's implementation is much better than urxvt's. For example, rxvt doesn't rewrap until you reach the bottom of the screen - this makes no sense to me. Rxvt cuts double wide (CJK) characters in half, Gnome-terminal wraps them correctly. When the alternate screen is present (such as when "less" or "mc" is running) the content underneath (the one you get back when you quit the app) is not rewrapped in rxvt, only in Gnome-terminal. When you resize the window the scrollbar jumps back to the bottom in Rxvt, while it does its best to keep it around the currently visible content in Gnome-terminal. I tried to take care to get all the minor details as perfect as possible, I encourage you to give it a try and I hope you'll like it more than rxvt's rewrapping

[curaga]

This is fantastic! But I guess it has a performance impact, the terminal has to keep all the output in a buffer of some sort, and reprint it to the new size of the terminal. Before, the terminal could just render the output, and then throw the text strings away, right? Or have they always kept the actual strings in memory?

They keep them in the rollback buffer, but reflowing is some additional complexity.

[robclark]

How does it work, for the application to declare that *part* of the window is, say, "black, 80% opaque"? It's easy for a compositor to automatically make an entire window translucent, or to make the window decorations and border glassy (like Windows 7 does), but it's much harder for the application to tell the compositor that "everything is opaque except for this bit in the middle"...

surfaces can be ARGB, so if a app wants part of a window to be translucent, it just plugs in appropriate alpha component value

(application can declare an opaque-region, but that is simply an optimization hint for the compositor)

[Azpegath]

This is fantastic! But I guess it has a performance impact, the terminal has to keep all the output in a buffer of some sort, and reprint it to the new size of the terminal. Before, the terminal could just render the output, and then throw the text strings away, right? Or have they always kept the actual strings in memory?

[oleid]

fwiw, the screenshot-the-desktop approach is just fallback if you don't have a proper compositing window mgr.. and ARGB windows/surfaces are completely possible with wayland, probably easier since you don't have to worry so much about fallback paths (ie. non-compositing window mgr, etc)

The fallback for the non-composed desktop was not using a screenshot, but the current desktop wallpaper. I don't know how the composed case worked, though.

I don't know for sure, but I think what Rob's alluding to is the compositor should/could use the alpha transparency the application draws it's background with to do the blending. So if the alpha is 50% (128, 0x80) then the background will be blended 50% with what's behind it.

That would be the cleanest solution, IMHO. It might work for wayland, but I have a feeling it won't work for X11. AFAIR X11-windows are opaque, however, you can make the whole window transparent.

[paulmlewis]

How does it work, for the application to declare that *part* of the window is, say, "black, 80% opaque"? It's easy for a compositor to automatically make an entire window translucent, or to make the window decorations and border glassy (like Windows 7 does), but it's much harder for the application to tell the compositor that "everything is opaque except for this bit in the middle"...

I don't know for sure, but I think what Rob's alluding to is the compositor should/could use the alpha transparency the application draws it's background with to do the blending. So if the alpha is 50% (128, 0x80) then the background will be blended 50% with what's behind it.

[busukxuan]

How does it work, for the application to declare that *part* of the window is, say, "black, 80% opaque"? It's easy for a compositor to automatically make an entire window translucent, or to make the window decorations and border glassy (like Windows 7 does), but it's much harder for the application to tell the compositor that "everything is opaque except for this bit in the middle"...

I don't know too much about wayland. Wayland doesn't draw on behalf of the clients, and the client does all the drawing themselves, that's where my idea comes from. What I want to ask is: considering the above, does "drawing" include alpha information? If so, then does it mean that the client can control the transparency of different parts of its window?