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

[mdedetrich]

but that code is single threaded

Which is the problem, having the C library implementing some GUI/UI toolkit as single threaded is causing the issue. The whole point is that GUI/UI toolkits should be multithreaded/asynchronous to provide optimal experiences for the user.

Having C++ wrappers over such toolkits doesn't fix this problem. Qt might be an obvious exception here since the base library is written in C++ which has better support for multi-threaded code.

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

[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

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

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

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

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

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

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