Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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?pag...olor-WIP-Patch

  • #2
    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.
    Last edited by brent; 08-18-2020, 07:58 AM.

    Comment


    • #3
      Originally posted by brent View Post
      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.

      Comment


      • #4
        Originally posted by mdedetrich View Post

        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/mutte..._requests/1403

        Comment


        • #5
          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.

          Comment


          • #6
            This shows vanvugt at his best and his worst. Nice work but not ready for review until he fixes most regressions. The maintainers are pretty pissed about these immature MRs.

            Comment


            • #7
              Originally posted by aufkrawall View Post
              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?

              Comment


              • #8
                Originally posted by bug77 View Post
                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.

                Comment


                • #9
                  Originally posted by mdedetrich View Post
                  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).

                  Comment


                  • #10
                    Originally posted by bug77 View Post

                    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.

                    Comment

                    Working...
                    X