Live data from Hacker News

Fractional scales, fonts and hinting

blog.gtk.org

111–117 of 117 posts

Re: Fractional scales, fonts and hinting

#111

Earlier quoted context omitted.

Full hinting is a must-have if you turn AA off and use fonts that were designed to be hinted to a pixel grid. Fonts have several distinct periods where they were designed expecting that renderers would function a certain way. File format notwithstanding, one size does not fit all. You really do need to match your font to your renderer's settings.

that may well be, but for me, I choose no hinting, with AA activated, and if a font does not look good, I simply do not use it. IF i specifically REALLY wanted a font that required hinting to look good, I would make a special config for that particular font, but I would need some serious advantage to bother doing that

Why not use slight hinting then? FreeType explains it as only using the vertical hint but not the horizontal one and they recommend this as working well with cleartype fonts and pretty well with non-cleartype fonts.

Re: Fractional scales, fonts and hinting

#112
post #31

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…

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-0... + https://blog.gtk.org/files/2024/03/hinting-125.png You can really spot the difference.

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.

Re: Fractional scales, fonts and hinting

#113
post #87

Earlier quoted context omitted.

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

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

To scale in linear RGB colorspace, you first need to do a colorspace transform on the entire buffer, then scale, then do another colorspace transform. I can't find any device that does this in a single step correctly, except for some rare GPU extensions.

Re: Fractional scales, fonts and hinting

#114

Earlier quoted context omitted.

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

> 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. To scale in linear RGB…

To quote the Intel docs:

> Plane scaling is [sic] supports both linear and non-linear scaling modes. The scaling mode is programmed in the PS_CTRL. In HDR mode, scaling and blending operations are generally performed in linear mode.

To be limited to sRGB would mean, that the hardware is pretty much limited to SDR. That would make it unusable in mainstream market today; just good enough for low-end SBCs.

Re: Fractional scales, fonts and hinting

#115
post #104

Earlier quoted context omitted.

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.

It also works great with almost but not-quite HiDPI screens such as commonly available and cheap 4K 27" monitors. You can scale them at 150% and with ClearType it looks as good as super expensive 6K Mac screen. In fact since cleartype effectively triples resolution I guess you get quality of 12K display?

> In fact since cleartype effectively triples resolution

Only horizontally (is 4K a double or a quadruple resolution of 1080p?), and only if you don't care about color (saturation, hue).

Re: Fractional scales, fonts and hinting

#116

Earlier quoted context omitted.

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.

Subpixel AA does not have significant benefits over greyscale AA on 1440p or similar displays, and it always have all the downsides. If you're rocking a large 1080p display and never share your screen (including screenshots), sure.

As the field of view taken by pixels decrease (DPI only has meaning when combined with distance to retina), anti-aliasing becomes less and less relevant. But until then, greyscale remains the lesser evil.

Re: Fractional scales, fonts and hinting

#117
post #104

Earlier quoted context omitted.

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.

It also works great with almost but not-quite HiDPI screens such as commonly available and cheap 4K 27" monitors. You can scale them at 150% and with ClearType it looks as good as super expensive 6K Mac screen. In fact since cleartype effectively triples resolution I guess you get quality of 12K display?

It does not triple resolution. Subpixel rendering can only be used to smooth full pixel lines - this introduces color fringing on the sides of font glyphs, but one that can sometimes be ignored when the smoothed lines are thick enough to distract.

If you used subpixel rendering to render lines of fractional pixel thickness, it would just appear as a single-pixel line of the wrong color. The same happens if you render line thicknesses up to 1 1/3 pixels wide, but offset to not match any pixel boundary.

At the same time, subpixel antialiasing can only be used with a specific subpixel layout, in the direction sof the subpixels. For regular desktop LCD panels, this means smoothing of vertical lines only, making characters like "o" look funky and uneven.

With that in mind, a 4k panel with subpixel antialiasing does not look anything like a 6k panel with greyscale antialiasing ("super expensive mac screen" is not relevant, apart from display technology differences not related to resolution or aliasing).

Post reply on HN