Investigation: Font glyph rendering doesn't seem quite right.

[ben-clayton]

I've spent a few days looking into what exactly I'm finding disagreeable, and I have a few theories starting from most likely to least:

• By dropping the integer-pixel offsets, I've screwed up the hinting. I would have thought this would be simple to confirm by comparing glyphs I've rendered to glyphs produced by another application - I tried, and I couldn't really convince myself that this was the problem.
• Gamma isn't quite right. I had a play trying to compensate the curve in the shader used to display the rasterized glyphs - nothing I tried made it look significantly better.
• It's in my head. I've spent so long with my retina MBP looking at the lovely smooth fonts, that all other displays just look crap.

I will need to spend a bit more time investigating what isn't quite right here.

[nieware]

First of all, thanks for starting this project! I think there's a lot of promise in a native Go UI library and I'm looking forward to how it will develop!

I don't know about you, but what I find disagreeable about the fonts in GXUI is the lack of subpixel rendering. This has become so commonplace nowadays that fonts rendered with "conventional" smoothing techniques look "not quite right", as you wrote, at least on low-DPI screens. I have investigated a bit, and unfortunately freetype-go doesn't support subpixel rendering at the moment - which makes sense considering that the initial application was drawing text into images, but is unfortunate when you want to use it for a UI library. I'd even volunteer to do it, but there's a lot of theory involved that I'm not familiar with, so the task is pretty daunting. Maybe looking at the subpixel rendering code of the original freetype library and porting that to go is more feasible?

[ben-clayton]

First of all, thanks for starting this project! I think there's a lot of promise in a native Go UI library and I'm looking forward to how it will develop!

Thank you and welcome.

I don't know about you, but what I find disagreeable about the fonts in GXUI is the lack of subpixel rendering.

This is certainly likely to be a contributor to the poor quality and I definitely would love to have support for sub-pixel rendering, but is unfortunately a minefield for patents. Last time I checked sub-pixel rendering was still disabled by default in freetype.

I'm sure there's other things that could be done to improve the quality though. Glyphy looks interesting, although the pre-computation and rendering cost seems quite scary.

[dmitshur]

Another factor to take into account is that anti-aliasing is turned on with 4 samples:

https://github.com/google/gxui/blob/e60202108a86126a804f4ca9062aa0cacda092e7/drivers/gl/viewport.go#L71

glfw.WindowHint(glfw.Samples, 4)

[ben-clayton]

MSAA does not affect texture sampling. It is only used to anti-alias the polygon edges, which in the case of the glyphs should always be fully transparent.

[dmitshur]

Ah, so each glyph is just a textured quad? I see; I hadn't looked into its details yet. In that case you are right, MSAA should not affect it.

[ben-clayton]

Ah, so each glyph is just a textured quad?

Yes. A very brief overview of how they work:

• Font.DrawRunes is called to draw a bunch of glyphs.
• As windows can be dragged between differing DPI displays, the glyph table is looked up for the current resolution.
• Each rune is iterated over and is checked to see if it has already been rasterized. If it hasn't then the glyph gets rasterized into the first page (texture) with free space.
• Rasterized runes are then sent to the blitter to be rendered.
• blitter.blitGlyph accumulates these calls into a buffer so that glyphs can be drawn in batches. These batches get submitted when the glyph page changes or something other than a glyph needs to be drawn. This is one of the reasons Font.LoadGlyphs exists - having frequently used glyphs in separate glyph pages will increase draw call count and severely impact render performance.