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)

[tokyo4j]

Maybe we should look a bit into scenefx and help to upstream some features.

Sure, worth exploring.

An important precondition in wlroots is that it maintains multiple renderers (egl, vulkan and pixman). So when they implement rounded corners or gradients, they'll need to modify shader programs of all the renderers.

Likely also not that important for most systems but only having the monolithic titlebar buffers will also increase the ram and vram usage because in the vast majority of cases we can't re-use it (size difference + title being backed in to keep the font nice).

Just to clarify: in my proposed approach (not implemented yet), we can keep the RAM/CPU usage minimal by using wlr_scene_rect for backtrounds and wlr_scene_buffer for fonts in case where the background color is solid and corner radius is zero. So we can add an message in our manpage to encourage embedded programmers to use solid background color and zero corner radius.

[Consolatis]

After playing around with the horizontal branch for a bit I am fine with rendering the titlebar all at once. I am still not particularly happy that in some major situations (solid or vertical gradients) we are doing way more GPU work than necessary but if the majority of the other devs think its the way to go then I am fine with it.

A random thing I noticed is that the squared corners on maximize don't work, something like this seems to fix it: tokyo4j/labwc@scaled-titlebar-buffer...Consolatis:labwc:tmp/horz_gradiant_fix_squared_on_max

[tokyo4j]

A random thing I noticed is that the squared corners on maximize don't work, something like this seems to fix it

Yeah there's a lot of more work to do. Thanks for making a patch.

Another broken stuff in my branch is ToggleKeybinds indicator. Currently we just change the color of the top border, but I wonder how or whether we should apply it to my approach. In my opinion, our current behavior is just a quick hack that makes use of our implementation details and I'm not happy that it doesn't work for maximized or CSD windows. I think we can continue this discussion on this topic in #1966.

[Consolatis]

Agree on the ToggleKeybinds indicator being just a quick hack, I guess technically we could simply overlay a wlr_scene_rect on top of the titlebar if we want to preserve the current behavior and don't want to draw the whole titlebar again when the indicator changes but I am very much open to alternative visual designs as well.

[johanmalm]

After playing around with the horizontal branch for a bit I am fine with rendering the titlebar all at once. I am still not particularly happy that in some major situations (solid or vertical gradients) we are doing way more GPU work than necessary but if the majority of the other devs think its the way to go then I am fine with it.

Thanks @Consolatis

I intuitively like the titlebar "all at once" approach, but get that it's not a straight forward choice. Well, if we go for 0.19.0 porting first, we've got some time to ponder it further. Sometimes good ideas come with a few days to think 😄

[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 ?

[tokyo4j]

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

Yes, we can do that for my scaled_titlebar_buffer by adding title, font, and align arguments to scaled_titlebar_buffer_create().

But if we try to support gradients for other text boxes in general like menu items or window switcher items, keeping support for subpixel antialiasing may be difficult.

Let me explain my thoughts. When I was working on horizontal gradient support for the titlebar, I was also thinking of how we can apply gradients to menu items or window switcher items. I thought this can be achieved by adding scaled_texture_buffer (or extending scaled_rect_buffer) which shares the common helpers to draw gradients with scaled_titlebar_buffer, and by replacing existing wlr_scene_rect with scaled_texture_buffer. But if we try to directly draw texts into this scaled_texture_buffer, we can no longer depend on scene-graph API to draw and move texts inside the items, and we will need to let scaled_texture_buffer remember the texts it contains and their positions, just like what wlr_scene_tree does.

But anyway, now I agree with @jlindgren90 - dropping subpixel antialiasing is undesirable, even if it's only done for gradient backgrounds. So besides shaping up my horizontal gradient support for the titlebar (with texts embedded in the buffer), I'll try to figure out how we can apply gradient also for other text boxes without losing subpixel antialiasing, in a maintainable way.