Announcement

Collapse
No announcement yet.

KDE Kicks Off February With More Bug Fixes, 30-bit Color Support For Plasma On X11

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

  • #31
    Originally posted by Vistaus View Post
    But thank *you* for filing one bug report for a browser I don't even use on a regular basis.
    In bird's brain logic is like: 'I've reported this bug, so I can lie and spread propaganda about Linux now!'.

    Comment


    • #32
      Originally posted by aufkrawall View Post
      you can do the maths in higher bitdepth intermediate format and then dither to 8 bit output, ideally this is completely free of any noticeable banding too.
      If you can see the banding, you'll see the noise (unless at really high DPI).

      Originally posted by aufkrawall View Post
      10 bit output format is highly overrated on internet forums.
      Lots of 10-bit monitors are really 8-bit + FRC. It's better for the monitor do dither, because it can dither at the native framerate, which makes it harder to see. It also avoids your CPU/GPU from having to do unnecessary redraws, just to recalculate the dither.

      Comment


      • #33
        Originally posted by krzyzowiec View Post
        Being able to click a webpage link in order to install a plugin that modifies the UI without having to restart is one neat feature that would be impossible in a compiled language.
        Um, not if the component in question is in a runtime-loaded shared library.

        Comment


        • #34
          Originally posted by coder View Post
          If you can see the banding, you'll see the noise (unless at really high DPI).
          Really doubt that anyone can see it with displays that aren't utter garbage. There is always dither anyway when adjusting color in your display's OSD (else there is banding), and I think amdgpu driver also always does it. Proper dither (temporal, transparent, proper patterns...) is much harder to notice than screwed up one.

          Originally posted by coder View Post
          Lots of 10-bit monitors are really 8-bit + FRC. It's better for the monitor do dither, because it can dither at the native framerate, which makes it harder to see. It also avoids your CPU/GPU from having to do unnecessary redraws, just to recalculate the dither.
          There is no redraw caused by dithering applied by GPU before scan-out. Also GPU dithering is always at full refresh rate, unless there is panel self refresh or VRR. And with VRR, you very likely aren't looking at monochrome areas such as system UIs where there might be the slightest chance for hawk-eyed people to spot dither with a magnifier.

          Comment


          • #35
            Originally posted by aufkrawall View Post
            There is no redraw caused by dithering applied by GPU before scan-out. Also GPU dithering is always at full refresh rate, unless there is panel self refresh or VRR.
            But, to get GPU dithering, you'd have to create a HDR framebuffer. Sure, same thing you'd have to do to get HDR output to a monitor, though.

            However, as long as it's applied at every refresh, I don't much care if it's the GPU or the monitor that's doing it. Maybe it becomes an issue for using things like Display Stream Compression.

            Originally posted by aufkrawall View Post
            with VRR, you very likely aren't looking at monochrome areas such as system UIs where there might be the slightest chance for hawk-eyed people to spot dither with a magnifier.
            Pretty much anywhere you'd notice banding is probably a good place to spot dithers. Sky is a good one.

            Comment


            • #36
              Originally posted by coder
              Um, not if the component in question is in a runtime-loaded shared library.
              No, not even then. Your runtime-loaded shared library must be compiled for a particular platform. On Gnome, you can load plugins from their site regardless of your platform.
              Last edited by krzyzowiec; 06 February 2022, 09:29 PM.

              Comment


              • #37
                Originally posted by krzyzowiec View Post
                No, not even then. Your runtime-loaded shared library must be compiled for a particular platform. On Gnome, you can load plugins from their site regardless of your platform.
                Eh, you made a fairly absolute statement about it being impossible. I'm just pointing out that there are ways. Even with respect to your point about platform, there could be a repo with builds of common plugins for widely-used platforms.

                I'm not saying it's better than scripting (depending on the specifics), but just not actually impossible.

                Comment


                • #38
                  Originally posted by coder
                  Eh, you made a fairly absolute statement about it being impossible. I'm just pointing out that there are ways.
                  Yes, if you add a repo to your system. Not what I was talking about.

                  Comment


                  • #39
                    Originally posted by krzyzowiec View Post
                    Yes, if you add a repo to your system. Not what I was talking about.
                    You said: "Being able to click a webpage link in order to install a plugin that modifies the UI without having to restart"

                    What I had in mind is that the link includes a sub-path for each of several common platforms, which can be filled in automatically.

                    In fact, I always see these "one-click install" links to .ymp files, on software.opensuse.org. So, that'd be a real example. You just need a package that installs some runtime-loaded extension to your app, which the app can detect, reload, and refresh via inotify().

                    Comment

                    Working...
                    X