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

[microcode]

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

Compressed formats do not transmit dithered tones well, typically, and I think most image and video decoders do not dither 10-bit results when rendering to 8-bit buffers.

[mdedetrich]

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).

I think the main issue here is the host language that GUI toolkits are written in C is one of the major causes of this. Writing bug free multithreaded code in C is really hard however other languages, both low level (i.e. Rust) and high level (Scala) make dealing with this problem very easy, i.e. offloading certain tasks to specific threads/thread pools or IO driven event loops (which are common in network bottlenecked code, i.e. webservers).

Although its true that there is a cost to context switching which can be more apparent on lower spec'ed machines, if done correctly this is largely a non issue assuming you are doing things correctly (i.e. only processing what is strictly necessary on the UI/event thread). Even on single core machines this has benefits although you wouldn't be using threads as an abstraction (i.e. difference between concurrency vs parallelism).

[wswartzendruber]

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.

You shouldn't see banding with SDR luminance and Rec.709 color. Now bring in HDR luminance (like HLG) and Rec.2020 color. 10-bit suddenly isn't so useless anymore.

[pal666]

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.

it'll get you back to x11's extra round trips to window manager. there are ways to do crash resilience with less overhead

[dragon321]

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.

I think they made some improvements with 3.36 (or 3.34) and it's indeed working better than last time I've tried. Still not perfect so glad to hear more improvements are coming.

[pal666]

I'd rather see more efforts spent directly on HDR support.

what direct hdr you have in mind? the one with 8 bit per channel?

[pal666]

I think the main issue here is the host language that GUI toolkits are written in C is one of the major causes of this

qt is written in c++. windows/macos toolkits are also not written in c. even poor gtk has c++ bindings

[Britoid]

qt is written in c++. windows/macos toolkits are also not written in c. even poor gtk has c++ bindings

Right, even if you use the C++ bindings you're still going to be talking to code written in C.

[pal666]

Right, even if you use the C++ bindings you're still going to be talking to code written in C.

but that code is single threaded

[aufkrawall]

Compressed formats do not transmit dithered tones well, typically, and I think most image and video decoders do not dither 10-bit results when rendering to 8-bit buffers.

I did not say that content should be saved in 8 bit + dithering. mpv renderer offers dithering, nothing extraordinary about it.