30-bit Deep Color For GNOME On Wayland Will Likely Take Some Time

[phoronix]

Phoronix: 30-bit Deep Color For GNOME On Wayland Will Likely Take Some Time

As written about at the start of the month, well known GNOME contributor Daniel van Vugt of Canonical/Ubuntu has added tackling deep color support to his TODO list for being able to properly handle 30-bit color on the desktop...

http://www.phoronix.com/scan.php?page=news_item&px=30-bit-GNOME-Color-WIP-Patch

[brent]

There's another WIP merge request that might be worth reporting: Handling of input events on a separate thread. FINALLY! If everything works correctly, this will mean input handling and mouse cursor updates won't be stalled anymore by a busy main thread (as long as hardware cursor planes are used). This should have been done years ago, but at least it's being implemented now. In the mean time, gnome-shell and mutter received some serious optimizations and eliminations of blocking I/O so that stalling is less of an issue, but it still happens sometimes.

I'd still prefer a clean process divide between a barebones compositor and the desktop shell, which would allow for some crash resilience, but that would be a much more invasive change.

[mdedetrich]

There's another WIP merge request that might be worth reporting: Handling of input events on a separate thread. FINALLY! If everything works correctly, this will mean input handling and mouse cursor updates won't be stalled anymore by a busy main thread (as long as hardware cursor planes are used). This should have been done years ago, but at least it's being implemented now. In the mean time, gnome-shell and mutter received some serious optimizations and eliminations of blocking I/O so that stalling is less of an issue, but it still happens sometimes..

Is this specific to Wayland or is it a general Gnome thing?

And yes, UI/GUI for dummies means that you always do UI/input work on another thread. I am surprised it took this so long to implement.

[brent]

Is this specific to Wayland or is it a general Gnome thing?

And yes, UI/GUI for dummies means that you always do UI/input work on another thread. I am surprised it took this so long to implement.

On X, input events, cursor updates etc. are all handled by the X server fully asynchronous, so these improvements mostly apply to Wayland. Note that the MR doesn't actually include actual asynchronous cursor updates (yet?), but in the end that's going to happen one way or another:

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403

[aufkrawall]

Putting efforts into 10 bit presentation support is a waste of time unless later HDR support can profit by it, as you can dither and won't see grain nor banding with 8 bit output anyway.
I'd rather see more efforts spent directly on HDR support.

[bug77]

Putting efforts into 10 bit presentation support is a waste of time unless later HDR support can profit by it, as you can dither and won't see grain nor banding with 8 bit output anyway.
I'd rather see more efforts spent directly on HDR support.

Strongly disagree. It's not easy to get banding using 8bpc, but it's certainly possible. I've seen it happen mostly with greys.

Also, did I read the article right or is the fix really moving away from GBM and towards EGL?

[aufkrawall]

Strongly disagree. It's not easy to get banding using 8bpc, but it's certainly possible. I've seen it happen mostly with greys.

Then it's not rendered in >8 bit and dithered down to 8 bit, i.e. done wrong.

[caligula]

And yes, UI/GUI for dummies means that you always do UI/input work on another thread. I am surprised it took this so long to implement.

GUI toolkits often use the same thread for orchestrating GUI logic & events and user's application logic. It works fairly well if the user manages to offload slow processing to another thread, but the problems start if your stuff takes too long. Previously (windows 3.1/9x/2k/xp), even the rendering used the same thread which resulted in partially drawn windows. However slow processing won't halt the whole program anymore as the rendering pipeline and/or low level event loop probably use other threads. There's a disadvantage if you use separate threads because with multiple threads you need synchronization. But there are lock-free structures that are not that slow. Anyway, I think all these decisions come with some drawbacks. The problem with multi-threaded GUIs is that they might perform slower on really low end hardware, but then again you might be able to eliminate sources of GUI freezes (that appear due to use of blocking I/O and sloppy programming practices in the application logic).

[caligula]

Strongly disagree. It's not easy to get banding using 8bpc, but it's certainly possible. I've seen it happen mostly with greys.

Also, did I read the article right or is the fix really moving away from GBM and towards EGL?

The fact is, monitor manufacturers are integrating 10b color support in their devices. You're not supposed to do some 10b -> 8b conversions on the GPU. The GPU/computer should just deal with 10b colors. Something like 90% of 4k screens already support 10b colors. Sadly, only the top 10% do it natively without FRC.

[Mthw]

Is this specific to Wayland or is it a general Gnome thing?

And yes, UI/GUI for dummies means that you always do UI/input work on another thread. I am surprised it took this so long to implement.

I currently have a problem with KDE Plasma wayland session where the entire desktop runs at 20fps with nothing GPU or CPU heavy running in the background, and the mouse movement is also affected. Anyone else seen this behavior? I use amdgpu and my other (older) laptop with intel iGPU doesn't have this issue.