27 ms·

Fractional scales, fonts and hinting

216 points by vyskocilm 3y ago

unwind 3y ago
As a long-time developer against GTK (I started using it back in the 1.x days in the late 90s) this is really awesome to see. I enjoyed the side-by-side comparisons of the old vs new renderer, and especially the idea of homing in on particular letters ('T' and 'e') and extracting them, that really made the improvement clear. Cool stuff, and many thanks to the developers who keep pushing the GTK stack forwards.
- EasyMark 3y ago
  against GTK? As in its philosophy? usage?
  - Narishma 3y ago
    Maybe they meant programming against GTK, not being against it?
  - nolist_policy 3y ago
    Probably as in 'linking against'.
  - blodkorv 3y ago
    He means utilizing GTK. In sweden its common to say "Utveckla mot xxx" Develop against, when talking about using a framework or library. I bet they say the same thing i Other germanic languages.
    - jhoechtl 3y ago
      Works in German too but reads somewhat awkward. Ich habe die Lösung gegen das GTK-framework entwickelt. It's ambiguous btw.
  - cstrahan 3y ago
    One of the definitions of "against", taken from Merriam Webster: > 4 b: in contact with > "leaning against the wall" OP's code is "in contact with" the public APIs provided by GTK. That is, OP uses the GTK library.
- kvemkon 3y ago
  The "old" renderer feels so new to me, that I'd like to see the comparison against GTK+ 3.0 with pango <=1.42. P.S. Since pango 1.44 some letters at some positions became blurry and some letters are more close to the previous one than being in the middle. Actually the later issue might be needed to prevent the first one, in theory. In practice, there might be other constraints, which force the corruption.
ggm 3y ago
Have the patents expired?
- azornathogron 3y ago
  If you're talking about the TrueType bytecode patents, yes, they expired nearly 14 years ago: https://freetype.org/patents.html https://freetype.org/patents.html But I don't think that's relevant here anyway, since the article refers to the auto-hinter which as far as I know was never patent-encumbered.
- deleted 3y ago
  [deleted]
ho_schi 3y ago
These are good news! I think this was a tough ride for the Gtk developers. Thanks! Background: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6190 https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6190 Basically gtk-hint-font-metrics=1 was needed with Gtk4 on non-HiDPI displays to get crisp text. Thanks to the change from 6190 above it is already automatically applied, when appropriate depending on which display is used. Mixed setups with multiple displays are common and Gtk4 cares about. The whole topic caused a heated issue before - because it depends on your own vision, taste and hardware. Apple avoids trouble and work by always using HiDPI displays. Attach a MacMini to a non-HiDPI display and you could recognize that the font rendering is awkward.
- DinaCoder99 3y ago
  > Attach a MacMini to a non-HiDPI display and you could recognize that the font rendering is awkward. Ironically for "always expose relevant options through system settings" Apple, you can still access font smoothing via command line, e.g. "defaults -currentHost write -g AppleFontSmoothing -int 3". You can use 0-3 where 0 disables it (default) and 3 uses "strong" hinting, with 1 and 2 in between.
  - mmmrk 3y ago
    Nit: the option does not hint, it emboldens text, as in, smears it a bit to make it appear thicker. And I think the default is actually 2?
    - DinaCoder99 3y ago
      Well whatever it does, I actually prefer it to hinting and always have. Whatever happens on linux makes the fonts look too thin for my personal taste. Regardless, I hope everyone agrees that hi dpi + no hinting (or smearing) looks the best.
      - redeeman 3y ago
        i always disliked hinting aswell, but thankfully one can just disable hinting on linux, and then fonts actually look fairly similar to what osx did(~10-15 years ago)
zidoo 3y ago
The Year of Linux on Desktop.
smallstepforman 3y ago
Haiku OS in my opinion solves this better by basing everything on default font size (in pixels). Eg it defaults to 12px, I used 20px for a 3840x2160 monitor. Some GUI widgets scale based on this. All text (when using be_default_font) scale based on this. Spacing / layout depends on this. The key difference (compared to a global x1.5 scaling factor) is that developers of each app decide how to use this information, so different parts of the GUI are scaled disproportionatily. Sloppy apps ignore this, but the devs are quickly notified. So you end up with text larger but GUI widgets can grow dis-proportionatily, so you can fine tune what is 125%, 150%, etc. Eg. ScrollBar can be 125%, toolbar 150%, text 233%. Haiku has had this since the beginning (even BeOS in the 90’s had this). By 2024, almost all non compliant apps have been fixed and support this. What Haiku needs is font setting per screen/resolution for multimonitor support. This way you can support mismatched monitors with different factors.
- WhyNotHugo 3y ago
  This sounds very much like using `em` units in CSS. 1em = the width of the letter "m". So it scales proportionally to font size. Relative units like this are usually considered best practice, because of the exact reasons that you've listed.
  - Someone 3y ago
    In user dialogs, Windows does/used to do that, too. https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getdialogbaseunits https://learn.microsoft.com/en-us/windows/win32/api/winuser/...: “The horizontal base unit returned by GetDialogBaseUnits is equal to the average width, in pixels, of the characters in the system font; the vertical base unit is equal to the height, in pixels, of the font. The system font is used only if the dialog box template fails to specify a font. Most dialog box templates specify a font; as a result, this function is not useful for most dialog boxes. For a dialog box that does not use the system font, the base units are the average width and height, in pixels, of the characters in the dialog's font. You can use the GetTextMetrics and GetTextExtentPoint32 functions to calculate these values for a selected font. However, by using the MapDialogRect function, you can avoid errors that might result if your calculations differ from those performed by the system.”
Klonoar 3y ago
This is fantastic work - there's a huge difference here for my eyes at least.
RedShift1 3y ago
The new renderer definitely looks better, but the letters still have something fuzzy about them. They don't feel crisp. Is this due to the font or due to the rendering?
- dspillett 3y ago
  The fuzzy is just an artefact of parts of the font not lining up with the monitor's pixel grid. There are ways to deal with this, but they can distort the font in other subtle ways, so no solution is perfect. In any case, it makes much less difference (almost none practically speaking) on hi-dpi displays. One of the reasons web designers have issues with text looking different between Windows and MacOS is that Windows' font renderer tries to force things to align with the pixel grid more, reducing a sharper result but slightly distorting some font characteristics. Apple's renderer is more true to the font's design, can can produce a little fuzziness like you see here. It also makes many shapes look a little more bold (at least on standard-ish DPI displays). A couple of old posts on the subject: https://blog.codinghorror.com/whats-wrong-with-apples-font-rendering/ https://blog.codinghorror.com/whats-wrong-with-apples-font-r..., https://blog.codinghorror.com/font-rendering-respecting-the-pixel-grid/ https://blog.codinghorror.com/font-rendering-respecting-the-.... Differences in sub-pixel rendering also make a difference, so where people have tweaked those options, or just have the colour balances on their screens set a little differently (intentionally or due to design/manufacturing differences) you might see results that differ even further for some users even on the same OS.
boomskats 3y ago
I'm curious - when you were doing research into the mechanics of hinting options, did you stumble onto any relevant discussion around allowing custom pixel geometries to be defined, to enable hinting on modern OLED / WRBG displays? There's a good thread on the topic here[0], with some people referring to it as 'ClearType 2' on the MS side [1]. On the oss side I know FreeType theoretically supports this[2], but I can't quite figure out how relevant the FreeType backend is to this most recent work. This is great work btw. [0]: https://github.com/snowie2000/mactype/issues/932 https://github.com/snowie2000/mactype/issues/932 [1]: https://github.com/microsoft/PowerToys/issues/25595 https://github.com/microsoft/PowerToys/issues/25595 [2]: https://freetype.org/freetype2/docs/reference/ft2-lcd_rendering.html#ft_library_setlcdgeometry https://freetype.org/freetype2/docs/reference/ft2-lcd_render...
- jsheard 3y ago
  AIUI the trend has been towards GUI frameworks dropping support for subpixel AA altogether, since that simplifies so many things[1], so I'm not holding my breath for the current limitations around unusual subpixel layouts being fully resolved on any platform. Apple made the switch to greyscale-only AA years ago, Microsoft is mid-transition with their newer GUI toolkits ignoring the system Cleartype setting and always using greyscale AA, and the GTK renderings in the OP are greyscale too. They're assuming that people will just get a HiDPI display eventually and then greyscale AA is good enough. [1] https://faultlore.com/blah/text-hates-you/#anti-aliasing-is-hell https://faultlore.com/blah/text-hates-you/#anti-aliasing-is-...
  - NoGravitas 3y ago
    Even on a screen with not-particularly-high DPI, grayscale AA is fine. Subpixel AA was a brilliant idea for the displays of 2005 (72-96 DPI), but it came with lots of downsides (like color fringing on dark backgrounds, or for users with astigmatism). Grayscale AA drops both the benefits and the drawbacks, but even at like 100 DPI, the difference is very marginal.
    - zozbot234 3y ago
criddell 3y ago
How does KDE (or is it Qt) font rendering compare?
- zamadatix 3y ago
  It supports the subpixel rendering mentioned at the end i.e. rendering subpixel hint out per channel.
- alwayslikethis 3y ago
  Qt6 has had fractional scale early on and still supports subpixel AA. Qt5 near the end of its life got fractional DPI scaling support on X11, but not on Wayland. KDE generally seems to handle scaling better nowadays compared to GNOME.
black3r 3y ago
Honestly I'd love it if Linux just implemented a solution similar to what Apple does, which is rendering everything at 2x and then downscaling it to screen's native resolution. (So my "3008x1692" on a 4K screen is actually rendered at 6016x3384). Modern GPUs are strong enough to do this without breaking a sweat, and the result is very crispy and functional. Fractional scaling could still exist as a fallback for older systems.
- zamadatix 3y ago
  This is what GTK used to do. It's less battery efficient for an inherently less crisp option though. It also gets less seemingly crisp after rescale for for the much more common "slightly higher than normal dpi closer to 1080p" type monitors (e.g. the 125% in the article) you don't typically find in Apple setups. Of course that's why subpixel rendering is all a bit moot on Apple devices. For a long time now they've just toggled the default font rendering to the equivalent of "none none" in this article and relying on the high quality screens the devices ship with/most users will plug in to make up for it.
- kuschku 3y ago
  That's what GTK used to do. The result looks much worse than fractional scaling, is much less crisp, uses a lot more battery, and means games run a lot slower.
  - vetinari 3y ago
    It is much more crispy for general graphics, with much less problem handling rounding errors and getting lost in antialiasing and fractions that you don't have a place to put into, since hardware does that for you globally for the entire framebuffer. It uses the same amount of battery power when done right (i.e. not using GPU, like GTK did, but the output encoder, like Apple does) and for games, compositors nowadays support overlays with exact virtual resolution and scaling, as the game needs.
    - kuschku 3y ago
      How is it much more crispy? If every widget supports fractional DPI correctly, the output will be bit-for-bit identical between the two different approaches. That said, the GPU and output encoder options chosen by Gtk3 and Apple have a major flaw: accelerated scaling is usually only available in sRGB colorspace, so you get either gamma-incorrect scaling or you need to fall back to a non-accelerated codepath.
jeppester 3y ago
I was a bit puzzled that the images were so blurry compared to the surrounding text. Then I realized that the 1px border around the before/after images forces them to be scaled down from an otherwise correct width of 600px to 598px. While not solving the blurriness completely it, removing the border with the inspector helps a lot. I think the remaining blurriness comes from the images using grey scale hinting rather than subpixel hinting (the hinted pixels are not colored)
- wrasee 3y ago
  Well spotted. Following this, I found opening each image in a new tab and switching between them worked as a nice way to compare. For convenience (second is hinted) + https://blog.gtk.org/files/2024/03/Screenshot-from-2024-03-06-21-44-21.png https://blog.gtk.org/files/2024/03/Screenshot-from-2024-03-0... + https://blog.gtk.org/files/2024/03/hinting-125.png https://blog.gtk.org/files/2024/03/hinting-125.png You can really spot the difference.
  - patrakov 3y ago
    You can, if you are in the target audience. I have a monitor running at 200% scale, and the scaled screenshots do not show much difference. Scaling the browser tab to 50% does reveal it.
zajio1am 3y ago
For some reason, FreeType broke proper grid-fitting and now requires environment variable FREETYPE_PROPERTIES=truetype:interpreter-version=35 to activate it.
- NoGravitas 3y ago
  It's not quite right to say it broke proper grid-fitting, because that depends on what the fonts were designed and hinted for. The old one matches Windows 98 hinting (and therefore that era's core fonts), and the new one matches ClearType's hinting (and therefore that era's core fonts).
zajio1am 3y ago
> The idea is that we just place glyphs where the coordinates tell us, and if that is a fractional position somewhere between pixels, so be it, we can render the outline at that offset just fine. This approach works—if your output device has a high-enough resolution (anything above 240 dpi should be ok). So it just requires 6x more memory, GPU power and HDMI/DP bandwidth and prevents usage of large monitors ...
- Narishma 3y ago
  Don't high dpi screens consume more power as well?
deleted 3y ago
[deleted]
p0w3n3d 3y ago
When got my first Mac I was astounded when I saw the font rendering there. It's really the thing I am missing in my home Linux laptop
mouse_ 3y ago
[flagged]
bloopernova 3y ago
I wonder if we'll ever abandon resolution-based rendering for screens, instead using a PPI/DPI vector-based system? Since the 80s I've been wishing for a 300/600dpi resolution-independent screen. Sure, it's basically like wishing for a magic pony, but I was spoiled by getting a Vectrex[1] for a birthday in the 80s, and I really liked the concept. I know the Vectrex was a different type of rendering to the screens we use today, but I still find it fascinating. [1] https://en.wikipedia.org/wiki/Vectrex https://en.wikipedia.org/wiki/Vectrex
- globular-toast 3y ago
  I wish for this too. You can get tiny screens with that kind of pixel density. My ebook reader is 300ppi and my phone is almost 650ppi! It saddens me when I see people measuring things in pixels. It should all be measured relative to the font or perhaps the viewport size. The font size itself should just be how big the user wants the text which in turn will depend on the user's eyes and viewing distance etc. The size in pixels is irrelevant but is calculated using the monitor's PPI. Instead we get people setting font sizes in pixels then having to do silly tricks like scaling to turn that into the "real" size in pixels. Sigh...
  - CharlesW 3y ago
    > The font size itself should just be how big the user wants the text which in turn will depend on the user's eyes and viewing distance etc. So software "pixels" are relative units now, but you would have them get larger or smaller as the user moves closer to or further from the screen? (I think I'm not quite getting it, sorry.)
    - globular-toast 3y ago
      We're wishing for a screen with such a high pixel density it makes pixels a completely irrelevant implementation detail of the screen itself. So nobody would be setting their font size (or anything else) as some number of pixels, they would in fact set it in a real physical unit like cm/inches and that choice merely comes down to personal preference, eyesight and how far you are from the screen.
WhereIsTheTruth 3y ago
And still no proper gamma correction.. wich makes the whole thing useless, specially on low-DPI screens Nobody does it properly on linux, despite freetype's recommendations.. a shame.. https://freetype.org/freetype2/docs/hinting/text-rendering-general.html https://freetype.org/freetype2/docs/hinting/text-rendering-g... It's even worse for Light text on Dark backgrounds.. text becomes hard to read.. GTK is not alone Chromium/Electron tries but is wrong 1.2 instead of 1.8, and doesn't do gamma correction on grayscale text https://chromium-review.googlesource.com/c/chromium/src/+/5332813/1..2/skia/BUILD.gn https://chromium-review.googlesource.com/c/chromium/src/+/53... Firefox, just like Chromium is using Skia, so is using proper default values but ignores it for grayscale text too.. https://bugzilla.mozilla.org/show_bug.cgi?id=1882758 https://bugzilla.mozilla.org/show_bug.cgi?id=1882758 A trick that i use to make things a little bit better: In your .profile: export FREETYPE_PROPERTIES="cff:no-stem-darkening=0 autofitter:no-stem-darkening=0 type1:no-stem-darkening=0 t1cid:no-stem-darkening=0"
- username923409 3y ago
  Wow, I just tried those environment variables, and it makes a remarkable difference for the smoothness and fullness for every font. I'll probably be leaving this setting on until something breaks when it gets fixed, and I inevitably spend too much time trying to figure out why it's broken after forgetting what I changed. Thanks for the tip, though.
  - actionfromafar 3y ago
    100% I don't know what my life would like without such decisions...
- westurner 3y ago
  > This seems to fix the blurry fonts with Wayland instead of X: flatpak --socket=wayland run com.visualstudio.code --enable-features=UseOzonePlatform --ozone-platform=wayland https://github.com/flathub/com.visualstudio.code/issues/398 https://github.com/flathub/com.visualstudio.code/issues/398 : > Various font-related flags I found in solving for blurry fonts on wayland Is there an environment variable to select Wayland instead of XWayland for electron apps like Slack and VScode where fractional scaling with wayland doesn't work out of the box?
butz 3y ago
Font rendering in GTK 3 was pretty good, then they broke it in GTK 4, and even with new renderers fonts are not up to par with good old GTK 3.
xyzelement 3y ago
I don’t have anything expert to add here except this is somehow a shockingly difficult problem. When I boot into windows, the fonts especially in some applications look horrible and blurry because of my high DPI monitor. Windows has like 10 settings you can try to tweak high dpi fonts and man none of them look good. I think my Linux boot on the same machine has much better font smoothness and of course the MacBook is perfect. Somehow most windows systems I see on people’s desks now look blurry as shit. It didn’t use to be this way. I really don’t understand why high dpi monitors cause (rather than solve) this problem and I suspect windows has some legacy application considerations to trade off against but man - windows used to be the place you’d go to give your eyes a break after Linux and now it’s worse! I realize I am ranting against windows here which is the most cliched thing ever but really come on it’s like right in your face!
- vladvasiliu 3y ago
  I don't think it's the high DPI screens themselves that cause this on Windows, rather the fonts have changed. I'm pretty sure they used to be bit mapped, or had excellent hinting. Now that high dpi is common, maybe they figured that wasn't needed anymore. And indeed, on my 24", 4k monitor at "200%", windows is pretty sharp if I start it that way. If I change it while running, it becomes a shit-show. But when running at 100% on a FHD 14" laptop, sharpness is clearly lacking. Regarding the Linux situation, yes, it's subjectively better on that same laptop. But it depends a lot on the fonts used. Some are a blurry / rainbowy mess. However, on Linux, I run everything at 100% and just zoom as needed if the text is too small (say on the above 24" screen).
- eviks 3y ago
  Not sure this is shockingly difficult, especially when for a lot of Windows apps you can already deblur the fonts by clicking a high dpi compatibility setting of a given exe file
  - xyzelement 3y ago
    I’ve literally never had that compatibility setting make a difference in the cases I tried. I am sure it does something in certain cases where the blurryness has a certain root cause but not universally
eviks 3y ago
These comparisons should be presented with a dynamic switching of identically sized images with identically placed text instead of placing slightly different images side by side
devit 3y ago
I don't understand this. It seems that they: - Fail to properly position glyphs horizontally (they must obviously be aligned to pixels horizontally and not just vertically) - Fail to use TrueType bytecode instead of the autohinter - Fail to support subpixel antialiasing These are standard features that have been there for 20 years and are critical and essential in any non-toy software that renders text. How come GTK+ is so terrible? EDIT: they do vertical-only rather than horizonal-only. Same problem, needs to do both.
- audidude 3y ago
  > - Fail to properly position glyphs vertically (they must obviously be aligned to pixels vertically and not just horizontally) If you read the article carefully, it mentions it aligns vertically to the _device_ pixel grid.
- deleted 3y ago
  [deleted]
deleted 3y ago
[deleted]

216 points by vyskocilm 3y ago

As a long-time developer against GTK (I started using it back in the 1.x days in the late 90s) this is really awesome to see. I enjoyed the side-by-side comparisons of the old vs new renderer, and especially the idea of homing in on particular letters ('T' and 'e') and extracting them, that really made the improvement clear. Cool stuff, and many thanks to the developers who keep pushing the GTK stack forwards.

EasyMark 3y ago
against GTK? As in its philosophy? usage?
- Narishma 3y ago
  Maybe they meant programming against GTK, not being against it?
- nolist_policy 3y ago
  Probably as in 'linking against'.
- blodkorv 3y ago
  He means utilizing GTK. In sweden its common to say "Utveckla mot xxx" Develop against, when talking about using a framework or library. I bet they say the same thing i Other germanic languages.
  - jhoechtl 3y ago
    Works in German too but reads somewhat awkward. Ich habe die Lösung gegen das GTK-framework entwickelt. It's ambiguous btw.
- cstrahan 3y ago
  One of the definitions of "against", taken from Merriam Webster: > 4 b: in contact with > "leaning against the wall" OP's code is "in contact with" the public APIs provided by GTK. That is, OP uses the GTK library.
kvemkon 3y ago
The "old" renderer feels so new to me, that I'd like to see the comparison against GTK+ 3.0 with pango <=1.42. P.S. Since pango 1.44 some letters at some positions became blurry and some letters are more close to the previous one than being in the middle. Actually the later issue might be needed to prevent the first one, in theory. In practice, there might be other constraints, which force the corruption.

ggm 3y ago

Have the patents expired?

azornathogron 3y ago
If you're talking about the TrueType bytecode patents, yes, they expired nearly 14 years ago: https://freetype.org/patents.html https://freetype.org/patents.html But I don't think that's relevant here anyway, since the article refers to the auto-hinter which as far as I know was never patent-encumbered.
deleted 3y ago
[deleted]

ho_schi 3y ago

These are good news! I think this was a tough ride for the Gtk developers. Thanks! Background: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6190 https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6190 Basically gtk-hint-font-metrics=1 was needed with Gtk4 on non-HiDPI displays to get crisp text. Thanks to the change from 6190 above it is already automatically applied, when appropriate depending on which display is used. Mixed setups with multiple displays are common and Gtk4 cares about. The whole topic caused a heated issue before - because it depends on your own vision, taste and hardware. Apple avoids trouble and work by always using HiDPI displays. Attach a MacMini to a non-HiDPI display and you could recognize that the font rendering is awkward.

DinaCoder99 3y ago
> Attach a MacMini to a non-HiDPI display and you could recognize that the font rendering is awkward. Ironically for "always expose relevant options through system settings" Apple, you can still access font smoothing via command line, e.g. "defaults -currentHost write -g AppleFontSmoothing -int 3". You can use 0-3 where 0 disables it (default) and 3 uses "strong" hinting, with 1 and 2 in between.
- mmmrk 3y ago
  Nit: the option does not hint, it emboldens text, as in, smears it a bit to make it appear thicker. And I think the default is actually 2?
  - DinaCoder99 3y ago
    Well whatever it does, I actually prefer it to hinting and always have. Whatever happens on linux makes the fonts look too thin for my personal taste. Regardless, I hope everyone agrees that hi dpi + no hinting (or smearing) looks the best.
    - redeeman 3y ago
      i always disliked hinting aswell, but thankfully one can just disable hinting on linux, and then fonts actually look fairly similar to what osx did(~10-15 years ago)

zidoo 3y ago

The Year of Linux on Desktop.

smallstepforman 3y ago

Haiku OS in my opinion solves this better by basing everything on default font size (in pixels). Eg it defaults to 12px, I used 20px for a 3840x2160 monitor. Some GUI widgets scale based on this. All text (when using be_default_font) scale based on this. Spacing / layout depends on this. The key difference (compared to a global x1.5 scaling factor) is that developers of each app decide how to use this information, so different parts of the GUI are scaled disproportionatily. Sloppy apps ignore this, but the devs are quickly notified. So you end up with text larger but GUI widgets can grow dis-proportionatily, so you can fine tune what is 125%, 150%, etc. Eg. ScrollBar can be 125%, toolbar 150%, text 233%. Haiku has had this since the beginning (even BeOS in the 90’s had this). By 2024, almost all non compliant apps have been fixed and support this. What Haiku needs is font setting per screen/resolution for multimonitor support. This way you can support mismatched monitors with different factors.

WhyNotHugo 3y ago
This sounds very much like using `em` units in CSS. 1em = the width of the letter "m". So it scales proportionally to font size. Relative units like this are usually considered best practice, because of the exact reasons that you've listed.
- Someone 3y ago
  In user dialogs, Windows does/used to do that, too. https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getdialogbaseunits https://learn.microsoft.com/en-us/windows/win32/api/winuser/...: “The horizontal base unit returned by GetDialogBaseUnits is equal to the average width, in pixels, of the characters in the system font; the vertical base unit is equal to the height, in pixels, of the font. The system font is used only if the dialog box template fails to specify a font. Most dialog box templates specify a font; as a result, this function is not useful for most dialog boxes. For a dialog box that does not use the system font, the base units are the average width and height, in pixels, of the characters in the dialog's font. You can use the GetTextMetrics and GetTextExtentPoint32 functions to calculate these values for a selected font. However, by using the MapDialogRect function, you can avoid errors that might result if your calculations differ from those performed by the system.”

Klonoar 3y ago

This is fantastic work - there's a huge difference here for my eyes at least.

RedShift1 3y ago

The new renderer definitely looks better, but the letters still have something fuzzy about them. They don't feel crisp. Is this due to the font or due to the rendering?

dspillett 3y ago
The fuzzy is just an artefact of parts of the font not lining up with the monitor's pixel grid. There are ways to deal with this, but they can distort the font in other subtle ways, so no solution is perfect. In any case, it makes much less difference (almost none practically speaking) on hi-dpi displays. One of the reasons web designers have issues with text looking different between Windows and MacOS is that Windows' font renderer tries to force things to align with the pixel grid more, reducing a sharper result but slightly distorting some font characteristics. Apple's renderer is more true to the font's design, can can produce a little fuzziness like you see here. It also makes many shapes look a little more bold (at least on standard-ish DPI displays). A couple of old posts on the subject: https://blog.codinghorror.com/whats-wrong-with-apples-font-rendering/ https://blog.codinghorror.com/whats-wrong-with-apples-font-r..., https://blog.codinghorror.com/font-rendering-respecting-the-pixel-grid/ https://blog.codinghorror.com/font-rendering-respecting-the-.... Differences in sub-pixel rendering also make a difference, so where people have tweaked those options, or just have the colour balances on their screens set a little differently (intentionally or due to design/manufacturing differences) you might see results that differ even further for some users even on the same OS.

boomskats 3y ago

I'm curious - when you were doing research into the mechanics of hinting options, did you stumble onto any relevant discussion around allowing custom pixel geometries to be defined, to enable hinting on modern OLED / WRBG displays? There's a good thread on the topic here[0], with some people referring to it as 'ClearType 2' on the MS side [1]. On the oss side I know FreeType theoretically supports this[2], but I can't quite figure out how relevant the FreeType backend is to this most recent work. This is great work btw. [0]: https://github.com/snowie2000/mactype/issues/932 https://github.com/snowie2000/mactype/issues/932 [1]: https://github.com/microsoft/PowerToys/issues/25595 https://github.com/microsoft/PowerToys/issues/25595 [2]: https://freetype.org/freetype2/docs/reference/ft2-lcd_rendering.html#ft_library_setlcdgeometry https://freetype.org/freetype2/docs/reference/ft2-lcd_render...

jsheard 3y ago
AIUI the trend has been towards GUI frameworks dropping support for subpixel AA altogether, since that simplifies so many things[1], so I'm not holding my breath for the current limitations around unusual subpixel layouts being fully resolved on any platform. Apple made the switch to greyscale-only AA years ago, Microsoft is mid-transition with their newer GUI toolkits ignoring the system Cleartype setting and always using greyscale AA, and the GTK renderings in the OP are greyscale too. They're assuming that people will just get a HiDPI display eventually and then greyscale AA is good enough. [1] https://faultlore.com/blah/text-hates-you/#anti-aliasing-is-hell https://faultlore.com/blah/text-hates-you/#anti-aliasing-is-...
- NoGravitas 3y ago
  Even on a screen with not-particularly-high DPI, grayscale AA is fine. Subpixel AA was a brilliant idea for the displays of 2005 (72-96 DPI), but it came with lots of downsides (like color fringing on dark backgrounds, or for users with astigmatism). Grayscale AA drops both the benefits and the drawbacks, but even at like 100 DPI, the difference is very marginal.
  - zozbot234 3y ago

criddell 3y ago

How does KDE (or is it Qt) font rendering compare?

zamadatix 3y ago
It supports the subpixel rendering mentioned at the end i.e. rendering subpixel hint out per channel.
alwayslikethis 3y ago
Qt6 has had fractional scale early on and still supports subpixel AA. Qt5 near the end of its life got fractional DPI scaling support on X11, but not on Wayland. KDE generally seems to handle scaling better nowadays compared to GNOME.

black3r 3y ago

Honestly I'd love it if Linux just implemented a solution similar to what Apple does, which is rendering everything at 2x and then downscaling it to screen's native resolution. (So my "3008x1692" on a 4K screen is actually rendered at 6016x3384). Modern GPUs are strong enough to do this without breaking a sweat, and the result is very crispy and functional. Fractional scaling could still exist as a fallback for older systems.

zamadatix 3y ago
This is what GTK used to do. It's less battery efficient for an inherently less crisp option though. It also gets less seemingly crisp after rescale for for the much more common "slightly higher than normal dpi closer to 1080p" type monitors (e.g. the 125% in the article) you don't typically find in Apple setups. Of course that's why subpixel rendering is all a bit moot on Apple devices. For a long time now they've just toggled the default font rendering to the equivalent of "none none" in this article and relying on the high quality screens the devices ship with/most users will plug in to make up for it.
kuschku 3y ago
That's what GTK used to do. The result looks much worse than fractional scaling, is much less crisp, uses a lot more battery, and means games run a lot slower.
- vetinari 3y ago
  It is much more crispy for general graphics, with much less problem handling rounding errors and getting lost in antialiasing and fractions that you don't have a place to put into, since hardware does that for you globally for the entire framebuffer. It uses the same amount of battery power when done right (i.e. not using GPU, like GTK did, but the output encoder, like Apple does) and for games, compositors nowadays support overlays with exact virtual resolution and scaling, as the game needs.
  - kuschku 3y ago
    How is it much more crispy? If every widget supports fractional DPI correctly, the output will be bit-for-bit identical between the two different approaches. That said, the GPU and output encoder options chosen by Gtk3 and Apple have a major flaw: accelerated scaling is usually only available in sRGB colorspace, so you get either gamma-incorrect scaling or you need to fall back to a non-accelerated codepath.

jeppester 3y ago

I was a bit puzzled that the images were so blurry compared to the surrounding text. Then I realized that the 1px border around the before/after images forces them to be scaled down from an otherwise correct width of 600px to 598px. While not solving the blurriness completely it, removing the border with the inspector helps a lot. I think the remaining blurriness comes from the images using grey scale hinting rather than subpixel hinting (the hinted pixels are not colored)

wrasee 3y ago
Well spotted. Following this, I found opening each image in a new tab and switching between them worked as a nice way to compare. For convenience (second is hinted) + https://blog.gtk.org/files/2024/03/Screenshot-from-2024-03-06-21-44-21.png https://blog.gtk.org/files/2024/03/Screenshot-from-2024-03-0... + https://blog.gtk.org/files/2024/03/hinting-125.png https://blog.gtk.org/files/2024/03/hinting-125.png You can really spot the difference.
- patrakov 3y ago
  You can, if you are in the target audience. I have a monitor running at 200% scale, and the scaled screenshots do not show much difference. Scaling the browser tab to 50% does reveal it.

zajio1am 3y ago

For some reason, FreeType broke proper grid-fitting and now requires environment variable FREETYPE_PROPERTIES=truetype:interpreter-version=35 to activate it.

NoGravitas 3y ago
It's not quite right to say it broke proper grid-fitting, because that depends on what the fonts were designed and hinted for. The old one matches Windows 98 hinting (and therefore that era's core fonts), and the new one matches ClearType's hinting (and therefore that era's core fonts).

zajio1am 3y ago

> The idea is that we just place glyphs where the coordinates tell us, and if that is a fractional position somewhere between pixels, so be it, we can render the outline at that offset just fine. This approach works—if your output device has a high-enough resolution (anything above 240 dpi should be ok). So it just requires 6x more memory, GPU power and HDMI/DP bandwidth and prevents usage of large monitors ...

Narishma 3y ago
Don't high dpi screens consume more power as well?

deleted 3y ago

[deleted]

p0w3n3d 3y ago

When got my first Mac I was astounded when I saw the font rendering there. It's really the thing I am missing in my home Linux laptop

mouse_ 3y ago

[flagged]

bloopernova 3y ago

I wonder if we'll ever abandon resolution-based rendering for screens, instead using a PPI/DPI vector-based system? Since the 80s I've been wishing for a 300/600dpi resolution-independent screen. Sure, it's basically like wishing for a magic pony, but I was spoiled by getting a Vectrex[1] for a birthday in the 80s, and I really liked the concept. I know the Vectrex was a different type of rendering to the screens we use today, but I still find it fascinating. [1] https://en.wikipedia.org/wiki/Vectrex https://en.wikipedia.org/wiki/Vectrex

globular-toast 3y ago
I wish for this too. You can get tiny screens with that kind of pixel density. My ebook reader is 300ppi and my phone is almost 650ppi! It saddens me when I see people measuring things in pixels. It should all be measured relative to the font or perhaps the viewport size. The font size itself should just be how big the user wants the text which in turn will depend on the user's eyes and viewing distance etc. The size in pixels is irrelevant but is calculated using the monitor's PPI. Instead we get people setting font sizes in pixels then having to do silly tricks like scaling to turn that into the "real" size in pixels. Sigh...
- CharlesW 3y ago
  > The font size itself should just be how big the user wants the text which in turn will depend on the user's eyes and viewing distance etc. So software "pixels" are relative units now, but you would have them get larger or smaller as the user moves closer to or further from the screen? (I think I'm not quite getting it, sorry.)
  - globular-toast 3y ago
    We're wishing for a screen with such a high pixel density it makes pixels a completely irrelevant implementation detail of the screen itself. So nobody would be setting their font size (or anything else) as some number of pixels, they would in fact set it in a real physical unit like cm/inches and that choice merely comes down to personal preference, eyesight and how far you are from the screen.

WhereIsTheTruth 3y ago

And still no proper gamma correction.. wich makes the whole thing useless, specially on low-DPI screens Nobody does it properly on linux, despite freetype's recommendations.. a shame.. https://freetype.org/freetype2/docs/hinting/text-rendering-general.html https://freetype.org/freetype2/docs/hinting/text-rendering-g... It's even worse for Light text on Dark backgrounds.. text becomes hard to read.. GTK is not alone Chromium/Electron tries but is wrong 1.2 instead of 1.8, and doesn't do gamma correction on grayscale text https://chromium-review.googlesource.com/c/chromium/src/+/5332813/1..2/skia/BUILD.gn https://chromium-review.googlesource.com/c/chromium/src/+/53... Firefox, just like Chromium is using Skia, so is using proper default values but ignores it for grayscale text too.. https://bugzilla.mozilla.org/show_bug.cgi?id=1882758 https://bugzilla.mozilla.org/show_bug.cgi?id=1882758 A trick that i use to make things a little bit better: In your .profile: export FREETYPE_PROPERTIES="cff:no-stem-darkening=0 autofitter:no-stem-darkening=0 type1:no-stem-darkening=0 t1cid:no-stem-darkening=0"

username923409 3y ago
Wow, I just tried those environment variables, and it makes a remarkable difference for the smoothness and fullness for every font. I'll probably be leaving this setting on until something breaks when it gets fixed, and I inevitably spend too much time trying to figure out why it's broken after forgetting what I changed. Thanks for the tip, though.
- actionfromafar 3y ago
  100% I don't know what my life would like without such decisions...
westurner 3y ago
> This seems to fix the blurry fonts with Wayland instead of X: flatpak --socket=wayland run com.visualstudio.code --enable-features=UseOzonePlatform --ozone-platform=wayland https://github.com/flathub/com.visualstudio.code/issues/398 https://github.com/flathub/com.visualstudio.code/issues/398 : > Various font-related flags I found in solving for blurry fonts on wayland Is there an environment variable to select Wayland instead of XWayland for electron apps like Slack and VScode where fractional scaling with wayland doesn't work out of the box?

butz 3y ago

Font rendering in GTK 3 was pretty good, then they broke it in GTK 4, and even with new renderers fonts are not up to par with good old GTK 3.

xyzelement 3y ago

I don’t have anything expert to add here except this is somehow a shockingly difficult problem. When I boot into windows, the fonts especially in some applications look horrible and blurry because of my high DPI monitor. Windows has like 10 settings you can try to tweak high dpi fonts and man none of them look good. I think my Linux boot on the same machine has much better font smoothness and of course the MacBook is perfect. Somehow most windows systems I see on people’s desks now look blurry as shit. It didn’t use to be this way. I really don’t understand why high dpi monitors cause (rather than solve) this problem and I suspect windows has some legacy application considerations to trade off against but man - windows used to be the place you’d go to give your eyes a break after Linux and now it’s worse! I realize I am ranting against windows here which is the most cliched thing ever but really come on it’s like right in your face!

vladvasiliu 3y ago
I don't think it's the high DPI screens themselves that cause this on Windows, rather the fonts have changed. I'm pretty sure they used to be bit mapped, or had excellent hinting. Now that high dpi is common, maybe they figured that wasn't needed anymore. And indeed, on my 24", 4k monitor at "200%", windows is pretty sharp if I start it that way. If I change it while running, it becomes a shit-show. But when running at 100% on a FHD 14" laptop, sharpness is clearly lacking. Regarding the Linux situation, yes, it's subjectively better on that same laptop. But it depends a lot on the fonts used. Some are a blurry / rainbowy mess. However, on Linux, I run everything at 100% and just zoom as needed if the text is too small (say on the above 24" screen).
eviks 3y ago
Not sure this is shockingly difficult, especially when for a lot of Windows apps you can already deblur the fonts by clicking a high dpi compatibility setting of a given exe file
- xyzelement 3y ago
  I’ve literally never had that compatibility setting make a difference in the cases I tried. I am sure it does something in certain cases where the blurryness has a certain root cause but not universally

eviks 3y ago

These comparisons should be presented with a dynamic switching of identically sized images with identically placed text instead of placing slightly different images side by side

devit 3y ago

I don't understand this. It seems that they: - Fail to properly position glyphs horizontally (they must obviously be aligned to pixels horizontally and not just vertically) - Fail to use TrueType bytecode instead of the autohinter - Fail to support subpixel antialiasing These are standard features that have been there for 20 years and are critical and essential in any non-toy software that renders text. How come GTK+ is so terrible? EDIT: they do vertical-only rather than horizonal-only. Same problem, needs to do both.

audidude 3y ago
> - Fail to properly position glyphs vertically (they must obviously be aligned to pixels vertically and not just horizontally) If you read the article carefully, it mentions it aligns vertically to the _device_ pixel grid.
deleted 3y ago
[deleted]

deleted 3y ago

[deleted]