Announcement

Collapse
No announcement yet.

GTK 4.14 To Provide Crisper Font Rendering, Better Fractional Scaling

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

  • #31
    Originally posted by ⲣⲂaggins View Post
    Users of this release are knowingly being used as beta testers for the new renderer. See https://gitlab.gnome.org/GNOME/gtk/-/issues/6411. I hope this doesn't end up being the version used in the next Ubuntu LTS.
    God, that issue thread is more proof GTK devs don't live in the real world. The new renderer is slow and full of bugs... so instead of reverting and waiting until it's ready, they tell the dev of Loupe (GNOME's default image viewer) to *hardcode Loupe to use the old renderer*? What the actual F*?!

    By the way, if anyone still needs even more proof GTK devs are insane: they think compositor handoff is "absolutely stupid" (direct quote from the merge request https://gitlab.gnome.org/GNOME/gtk/-...3#note_1292580), so half the Linux app ecosystem will never be able to survive Wayland compositor crashes.

    Comment


    • #32
      Originally posted by access View Post

      NB: macOS does not use subpixel-AA.
      But it used to. ​These days, Apple solves the problem by simply not certifying their OS to run on anything with less than 200 PPI.

      If you want the Intended GTK4 Experience, you can simply spend $1600 on an Apple Studio Display. It's thunderbolt-only so you probably can't drive more than one, and the refresh rate is a measly 60 Hz, but who cares about that when fonts in Gnome apps finally look better than they did in 2018?​

      Originally posted by Nocifer View Post
      Ah, so I guess it was Gnome's font rendering and fractional scaling that birdie was whining about, not Wayland's?
      Yeah. Wayland doesn't handle text rendering at all. It just passes images around.​

      Comment


      • #33
        Subpixel AA brings a shitload of complexity though... and not always with better result. Especially with non-traditional sub-pixel layouts. How well does e.g. ClearType work with BGR or WRGB OLED. IIRC it brings a performance penalty too as it trashes the glyph caches.

        Comment


        • #34
          Originally posted by ⲣⲂaggins View Post
          Users of this release are knowingly being used as beta testers for the new renderer. See https://gitlab.gnome.org/GNOME/gtk/-/issues/6411. I hope this doesn't end up being the version used in the next Ubuntu LTS.
          Well, given these are alpha/beta releases on the way to 4.14, you would hope they are using the users who have specifically chosen to be alpha and beta testers to test the new renderer.

          Comment


          • #35
            Originally posted by avis View Post

            Whoa, I didn't know GTK4 was so utterly bad. Thanks god I don't have or use a single app based on GTK4.

            I wonder what I'll do once XFCE inevitably faces the prospect of migrating from GTK3. That will be a disaster.
            Hopefully you're switch to MacOS or Windows and leave us alone lol

            Comment


            • #36
              Originally posted by mxan View Post

              God, that issue thread is more proof GTK devs don't live in the real world. The new renderer is slow and full of bugs... so instead of reverting and waiting until it's ready, they tell the dev of Loupe (GNOME's default image viewer) to *hardcode Loupe to use the old renderer*? What the actual F*?!
              You're reading too much into it.

              A special case is required for Loupe because of its ability to display extremely large images. The necessary support for that has not been optimised, so a recommendation to use the older renderer is not a problem. In fact the older renderer is kept in place for such reasons and sometimes even used instead of the newer renderers. The alternative is for all the applications to suffer from not getting these improvements (including the font improvements that are the discussion of the original posts).

              As for "being slower", that is reaching 1300fps in the benchmarks instead of 2000fps. It should make no difference to applications. Where it does make a difference, the reason needs to be identified and fixed. Its how development happens.

              Comment


              • #37
                Originally posted by mxan View Post

                God, that issue thread is more proof GTK devs don't live in the real world. The new renderer is slow and full of bugs... so instead of reverting and waiting until it's ready, they tell the dev of Loupe (GNOME's default image viewer) to *hardcode Loupe to use the old renderer*? What the actual F*?!
                Do you think things get released to the public only when all bugs are fixed? A lot of software have bugs and issues that have existed for multiple versions.

                Nothing wrong with an app momentarily forcing the use of the old renderer, that's what that ability exists for.

                Originally posted by mxan View Post
                By the way, if anyone still needs even more proof GTK devs are insane: they think compositor handoff is "absolutely stupid" (direct quote from the merge request https://gitlab.gnome.org/GNOME/gtk/-...3#note_1292580), so half the Linux app ecosystem will never be able to survive Wayland compositor crashes.
                "GTK devs", in this case, is referring to one person who was criticized for it by another Gnome dev. Make better posts, mxan.

                Also do you have a link to the comment bookmarked? lol
                Last edited by Myownfriend; 07 March 2024, 10:33 PM.

                Comment


                • #38
                  Originally posted by access View Post
                  Subpixel AA brings a shitload of complexity though... and not always with better result. Especially with non-traditional sub-pixel layouts. How well does e.g. ClearType work with BGR or WRGB OLED. IIRC it brings a performance penalty too as it trashes the glyph caches.
                  In my MATE desktop the Gnome 2 fork, one can pick among "RGB, BGR, VRGB, VBGR" subpixel font rendering in GUI dialog.

                  There is performance penalty in HiDPI rendering too. But no one use it as excuse for refusing to support HiDPI monitors.

                  Subpixel AA can be compatible with WRGB OLED as well. It is just that they are not common enough for PC monitors yet. So support for them haven't been added.

                  Comment


                  • #39
                    Originally posted by billyswong View Post
                    There is performance penalty in HiDPI rendering too. But no one use it as excuse for refusing to support HiDPI monitors.
                    That's arguable. If a window is maximized, it's going to use the same resources whether it's scaled or not. The scaled app might even use less in some cases. The only time it definitely uses more is if the app is being scaled down on the compositor side.

                    Comment


                    • #40
                      Originally posted by devling View Post

                      I have to admit that MacOS have extremely good font rendering, and have had for many years. I'm not sure exactly what they are doing, but it looks noticeably better than any windows or linux installation I've seen so far. So I'd say it is solved, do that Apple does and you're good. I'm no Apple fan by any means, but this one thing they got nailed down really well!
                      Apple assumes everyone has a HiDPI screen and acts accordingly. As others mentioned, they have removed subpixel rendering from macOS. If you can't afford a HiDPI screen, you're not worthy of being an Apple customer. Go back to Windows, peon.

                      Comment

                      Working...
                      X