Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fractional scales, fonts and hinting

blog.gtk.org

Post reply on HN
Print view View original

91–100 of 117 posts

Re: Fractional scales, fonts and hinting

#91

Post by arghwhat »

boomskats wrote: post #20

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'…

You really don't want to do subpixel AA anymore.

For one, subpixels aren't just lines in some order - they can have completely arbitrary geometries. A triangle, 3 vertical slats, a square split in four with a duplicate of one color, 4 different colors, subpixels that activate differently depending not just on chromaticity but also luminance (i.e., also differs with monitor brightness instead of just color), subpixels shared between other pixels (pentile) and so on.

And then there's screenshots and recordings that are completely messed up by subpixels antialiasing as the content is viewed on a different subpixel configuration or not at 1:1 physical pixels (how dare they zoom slightly in on a screenshot!).

The only type of antialiasing that works well is greyscale/alpha antialias. Subpixel antialiasing is a horrible hack that never worked well, and it will only get worse from here. The issues with QD-OLED and other new layouts underline that.

The reason we lived with it was because it was necessary hack for when screens really didn't have anywhere near enough resolution to show decently legible text at practical font sizes on VGA or Super VGA resolutions.

Re: Fractional scales, fonts and hinting

#92

Post by audidude »

devit wrote: post #90

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+…

> - 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.

Re: Fractional scales, fonts and hinting

#93

Post by adgjlsfhk1 »

arghwhat wrote: post #89
delta_p_delta_x wrote: post #85

Earlier quoted context omitted.

This works seamlessly on Windows. My 1920×1080 15.6-inch laptop display is at 125%, and my 3840×2160 27-inch monitor is at 175%. Move a window between both, and the size automatically snaps to whichever monitor contains more than 50% of the window.

That isn't seamless - windows has many different was to handle HiDPI, and for a few of them, the window will violently change size as it moves across and will look completely wrong on the "unmatched" monitor, to the point of being completely useless on that monitor (way too big to see anything or way too small to read anything). What Wayland is doing is making it so the window looks the same size on all screens, with…

counterpoint: a little bit of cheating here is not a bad thing.

Re: Fractional scales, fonts and hinting

#94

Post by kccqzy »

grandinj wrote: post #27
smallstepforman wrote: post #14

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…

This is a very good idea

This is a bad idea because:

> Sloppy apps ignore this, but the devs are quickly notified.

Anything that increases friction for developers is bad. The API for HiDPI should be so seamless that the only thing developer does is to provide higher resolution bitmap icons.

Imagine what web app developers need to do when their users switch from a regular display to a HiDPI display. They do nothing; the browser knows how to scale on its down. And that should be the bar we are aiming for.

Re: Fractional scales, fonts and hinting

#95

Post by alwayslikethis »

some1else wrote: post #13
ho_schi wrote: post #4

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 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 commo…

> 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. You may personally find the output awkward, but typographers will disagree. They didn't always have high density displays. They did always have superior type rendering, with output more closely matching the underlying design. Hinting was used, but they did…

It's pretty unreadable when the font size becomes small enough on a non-HiDPI display. It's a usability issue.

Re: Fractional scales, fonts and hinting

#96

Post by kccqzy »

DinaCoder99 wrote: post #5
ho_schi wrote: post #4

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 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 commo…

> 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.

That option used to have a UI selection back in Leopard! I have no idea why they removed it in Snow Leopard but left the functionality there.

Re: Fractional scales, fonts and hinting

#97

Post by vetinari »

kuschku wrote: post #87
vetinari wrote: post #86

Earlier quoted context omitted.

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…

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.

> If every widget supports fractional DPI correctly

That is a big if.

> the output will be bit-for-bit identical between the two different approaches.

It won't be identical. When you do it on widget-by-widget basis, you eventually reach the end of your surface, so you may need to paint your antialiased pixels, but the space is beyond your surface.

When the framebuffer is being considered as one global surface, the scaler will do the antialiasing for you outside of your surface, so you won't hit this problem.

Another thing is Apple scales; they limit the error caused by the antialiasing to a group of pixels, either 8x8 or 9x9. The error caused by fractional scaling won't spread outside of this group.

But for the sake of argument, let's say that these errors are not noticable and we can ignore them.

> 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.

This could be output encoder specific; I'm not aware of such limitation, so I'm looking into Intel docs now (TGL ones, volume 12: Display Engine), cannot find any mention of it. Would you have any pointers?

Or do you mean specifically GPU (texture) scaling? I'm not that familiar with GPU part, but I would be surprised if that was true, when the hardware today considers LUTs for the buffers.

For older hardware, or for ARM SBCs, that could be very well true.

---

In the end, both approaches have their pros and cons: with the encoder scaling, you won't be ever pixel-perfect in fractional scales, just good enough; but with software managed fractional scaling, you are over-complicating the already complicated code, so it won't be bug-free, and in the end, might consume more power (and CPU cycles on your CPU!) than the brute-force approach of encoder scaling that is being offloaded to dedicated hardware.

Re: Fractional scales, fonts and hinting

#98

Post by alwayslikethis »

arghwhat wrote: post #91
boomskats wrote: post #20

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'…

You really don't want to do subpixel AA anymore. For one, subpixels aren't just lines in some order - they can have completely arbitrary geometries. A triangle, 3 vertical slats, a square split in four with a duplicate of one color, 4 different colors, subpixels that activate differently depending not just on chromaticity but also luminance (i.e., also differs with monitor brightness instead of just color), subpixels…

Subpixel AA is still more readable for non-HiDPI LCD screens, which are still the majority of desktop monitors sold today. It did work well enough for people to be using it for so long, and the situation with screens on desktop has mostly not changed.

Re: Fractional scales, fonts and hinting

#99

Post by alwayslikethis »

NoGravitas wrote: post #63
jsheard wrote: post #29

Earlier quoted context omitted.

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…

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.

At 110 DPI (27 inch 1440p) it's not that marginal for me. Even looking somewhat closely the difference is quite obvious. Subpixel AA is much more readable if the font size is small, and still looks sharper for most interface fonts.

Re: Fractional scales, fonts and hinting

#100

Post by vetinari »

enriquto wrote: post #58
vetinari wrote: post #17

Earlier quoted context omitted.

Both variants had their fans and anti-fans. Apple rendering was shape-preserving but blurry, Microsoft's shape-deforming but crisp. I personally like the Apple rendering, but I realize that many people around me don't. In the end, it is subjective.

There's more than two variants that you can be a fan of. I for one find both cases that you describe blurry, and can only stand truly clean, non-rescalable bitmap fonts.

Do you know, that with a good font (properly hinted, or with good autohinter), you can have identical results as with bitmap fonts? Antialiasing is not mandatory for scaled fonts, and snapping to grid is the raison d'etre of hinting.

If anything, bitmap fonts on older/crt monitors were as fuzzy as the scaled ones, and on lcds, too jagged, so that hunted their readability. For me, enabling antialiasing actually improved their appearance.

But then, I always disliked the X11 bitmap fonts as ugly; the Microsoft's MS Sans Serif was about the only bitmap font I could tolerate (nowadays, it is truetype too).

Post reply on HN