Horizontal gradient support

[tokyo4j]

My implementation for horizontal gradients in the titlebar

#2686 implements vertical gradients for titlebar. However, its design is fundamentally limited for vertical gradients. For example:

• It allocates a vertically-gradient, 1px-wide buffer for the titlebar and horizontally expands it when the window is resized.
• The gradient background is embedded into the title font buffer. This means the font buffer needs to be redrawn every time the window is resized if we apply the same approach for the horizontal gradients or other patterns (see "Gray vs subpixel antialias" section later for discussion).

So as an alternate approach, I made a dirty prototype of horizontal gradients support for titlebar: https://github.com/tokyo4j/labwc/tree/scaled-titlebar-buffer that rotates vertical gradients in #2686 by 90 degrees. In short, my implementation adds scaled_titlebar_buffer that renders the whole titlebar every time the window is resized, rather than expanding 1px-wide buffer. I think this approach is more flexible than #2686 and easily expandable for other complex patterns like borders.

Performance/memory overhead

But of course, this comes with costs of performance and memory. So I did a quick benchmark to evaluate the performance overhead of my implementation. In this benchmark, I opened an xterm window and used my simple uinput program to resize the window continuously. Here's the result:

As you can see, my approach shows more CPU usage than #2686 or labwc master by 2-3%, but less than openbox by 2-3%.

And as for memory consumption, my approach will consume approximately 4B * 20 * 1920 = 154KB if the window covers an entire FHD monitor.

Gray vs subpixel anti-aliasing

Another drawback in my approach is that it always falls back to gray anti-aliasing instead of subpixels if the background color is not solid. This will make the fonts slightly more blurry.

Question

I'd like to define our scope for gradient support. I think we can either:

1. Only support vertical gradients and avoid the overheads or the blurriness I raised above
2. Support horizontal gradients or other patterns with my approach, while accepting the overheads and the blurriness

I don't really have a strong preference on this. Either way, I will keep using solid titlebar color and my laptop is performant enough to handle the overhead.

Also, as I said in #2686 (comment), we can merge #2686 for now and we can apply my approach on top of it.

[Consolatis]

The important thing for me would be that we don't regress performance wise if we are using a solid color (or vertical gradient with #2686). If the user decides to use either of the gradients and is aware of their specific implications on extremely low-end hardware in increased memory->GPU bandwidth + CPU utilization everything is fine in my book.

The difference to the vertical gradients would likely be:

• as far as I understand the pixels in the vertical case are generated and uploaded as a texture once and then stretched during resize via the renderer
• with the approach here it would keep creating new textures on resize which (besides the CPU usage) would increase usage of the potentially limited DMA-capable "GPU" memory (which often has fragmentation issues on various chips). That is absolutely not a concern on usual desktop hardware but might be on some low-end SOCs.

@cillian64 feel free to chime in and correct me if I got something wrong here (for SOCs in general, not just the latest rpi5).

[tokyo4j]

Hm, that's fair. Indeed my approach will cause more CPU<->GPU communications for every window resize. Just for reference, creating a lab_data_buffer and rendering it will cause graphic API calls like glGenTextures(), glBindTexture() and glTexImage2D() (link).

An optimization to avoid this problem is, as I described in #2686 (comment), to render the titlebar only with wlr_scene_rect (inside scaled_titlebar_buffer abstraction) when <theme><cornerRadius> is zero. This will work at least for rpi as it doesn't use rounded corners by default AFAIR.

[cillian64]

as far as I understand the pixels in the vertical case are generated and uploaded as a texture once and then stretched during resize via the renderer

Yep, that should be how it works.

with the approach here it would keep creating new textures on resize which (besides the CPU usage) would increase usage of the potentially limited DMA-capable "GPU" memory (which often has fragmentation issues on various chips). That is absolutely not a concern on usual desktop hardware but might be on some low-end SOCs.

Pi1-3 have a specific CMA fragmentation issue due to the lack of MMU on the GPU. But this causes significant problems and makes GPU rendering unusable even without these gradients, which is why we use the pixman renderer on Pi1-3, so there's no texture upload and no worry about fragmentation for us at least on those boards.

On Pi4-5 (and I assume other modern SBC SOCs) the GPU has an MMU so can effectively defragment its memory. Doing texture uploads every frame is not great, but it shouldn't break anything, only hurt performance a bit.

An optimization to avoid this problem is, as I described in #2686 (comment), to render the titlebar only with wlr_scene_rect (inside scaled_titlebar_buffer abstraction) when is zero. This will work at least for rpi as it doesn't use rounded corners by default AFAIR.

I'd certainly appreciate that optimisation!

I've just done some testing on a few Pis:

• On Pi1, window resizing is already a bit of a painful affair (to say nothing of compiling labwc - definitely a tea-break event). Basic (vertical) titlebar gradient support #2686 actually seems to improve performance a bit over current master. The horizontal-gradient branch seems about the same as current master with default rpi-os theme
• On Pi3, the horizontal-gradient branch seems about the same as current master with default rpi-os theme.
• On a pi4, with the horizontal-gradient branch, performance is fine even with a really excellent/tasteless titlebar gradient

[johanmalm]

@cillian64 - thanks for testing. I've actually got a Pi1B in the drawer but have not booted it for a long time so you spared me the effort!

It feels to me like we should go for the horizontal gradients because:

1. Although theoretically the horizontal gradients are more demanding (e.g. due to loading textures every frame in the GPU case because the whole titlebar is handled as one big lump), in practice there is no discernable difference as seen on the Pi1/3/4 tests.
2. If this actually makes a noticable difference on very low-end hardware, there is the option to set <resize drawContents="no"/> or make use of the proposed if (!gradient && !rounded_corners) { /* use wlr_scene_rect */ } optimisation.

Having more code paths (e.g. treat horizontal gradients as special case) does not seem like a sensible option - not that anyone suggested it, but just saying 😄

So, is the way ahead:

1. Reveiw + merge Basic (vertical) titlebar gradient support #2686 after 0.8.4
2. Then add this on top.

Cc: @jlindgren90 (not sure you've seen this thread)

[jlindgren90]

I am not too happy about losing subpixel antialiasing of the title text. If we are going to render the whole titlebar into an image buffer, can we just render the text into that same buffer to continue supporting subpixel antialiasing (assuming the buffer is opaque)?

[johanmalm]

Sorry, forgot about the anti-aliasing when trying to conclude.

can we just render the text into that same buffer to continue supporting subpixel antialiasing (assuming the buffer is opaque)?

Great question. @tokyo4j ?