Originally posted by aufkrawall
View Post
Announcement
Collapse
No announcement yet.
30-bit Deep Color For GNOME On Wayland Will Likely Take Some Time
Collapse
X
-
Originally posted by caligula View PostGUI 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).
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).
- Likes 1
Comment
-
Originally posted by aufkrawall View PostPutting 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.
- Likes 3
Comment
-
Originally posted by brent View PostI'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.
- Likes 1
Comment
-
Originally posted by brent View PostThere'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.
Comment
-
-
Originally posted by microcode View PostCompressed 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.
- Likes 1
Comment
Comment