Hacker News Reader

Comment by leni536 | Hacker News Reader

Another pain point on text AA: Many renderers mix up colorspaces on antialiasing. For example freetype assumes a linear colorspace when calculating the antialiased bitmap but AFAIK both GTK and QT apply it directly on sRGB without any adjusting. The result is apparently thickened fonts when displayed black on white and thinned fonts when displayed white on black.

Edit: Some background can be read on [0].

[0] https://www.freetype.org/freetype2/docs/text-rendering-gener...

View on HN

I believe it's somewhat unavoidable as the fonts may also have co-evolved to work with renderers that work that way

Yes - fonts looked too thin and rather ugly when the color space "bug" was fixed in early Qt 5 (on Linux / more precisely, with FreeType glyph rendering) versions. The fix was reverted to fix the look of text.

Sure, that's what stem-thickening is meant to compensate in the cited article.

With high density monitors on the rise we should get rid of LCD (RGB rainbows) anti alias as its really just a hack.

I strongly disagree, also the way the article describes subpixel antialiasing is not entirely accurate. The thing is the boundaries between pixels don't actually exist, it's just a convention so we can address individual pixels and subpixels within them. But these subpixels are not at the same position within the pixels and this needs to be taken into account for antialiasing.

Also regarding hiDPI: I know that you just want to get rid of subpixel antialiasing but you really don't want to get rid of antialiasing in general. It's not really an issue with typefaces, but non-antialiased high-frequency patterns can easily generate unwanted Moiré patterns on you display regardless how high is your display resolution.

It’s pretty much arbitrary what we as an industry have decided “text” means (and this has changed over the years), and what features it ought to support. It’s largely “what our technology easily supports today”.

For example, most people expect antialiasing (i.e., subsampling across space) but we seem to have written off the idea of motion blur (i.e., subsampling across time), except in some games.

It’s be technically more accurate to draw a quickly-dragged mouse cursor with a (correctly computed) blur, but that’s not generally easy to render today. And motion blur of moving subpixel antialiased text sounds like a nightmare right now, but with the right abstractions it might not be.

Motion blur is only "accurate" if you assume that the viewer's eyeballs remain still and don't follow the moving object. Having said that not blurring isn't accurate either on current LCDs when the viewer follows the object. This is what black frame insertion is meant to correct.

Antialiasing (nominally) makes text easier to read. Motion blur makes everything it's applied to harder to see.

From my own reading experience, I found that individually lit "RGB" clusters tend to be white, wherease "GBR" is fuzzy(?) and "BRG" tends to appear purple on the left but green on the right. This is because the green subpixel contributes most to perceived brightness. I think it's fortunate that most displays locate them in the center.

I tried reproducing the results using actual Cleartype with black lines on white backgrounds, and "orange-blue" vertical lines appear blurrier than "black" vertical lines.

Pretty much no one wants to get rid of antialiasing in general.

I use only grayscale antialiasing, even on LoDPI screens. It looks great. Subpixel adds bad color fringes.

Doesn't it depend on the screen and user preference though? On my old Thinkpad's screen grayscale antialiasing looks awful (fuzzier and harder to read), to the point where I've filled bugs when some aspect of a program's UI doesn't obey my system settings.

New high-end PCs indeed use high DPI displays, but color LCD monitors are now used in cars, dishwashers and microwaves. These are not high-DPI, and they often lack CPU and GPU power to handle high DPI.

Here's a library I've made for an embedded Linux device: https://github.com/Const-me/nanovg At 5" 800x480, subpixel AA improved text a lot.

Addressing subpixels according to their spatial location is no way a hack.

Qt does do gamma correction when it comes to text rendering.

Maybe for blending, white on black text and things like that - after calculating shades the "wrong" way for compatibility with fonts' built-in expectations. See my other comment about that.

Reply on news.ycombinator.com