Why is Shiny's text rendering quantizes to the pixel grid?

[Elias Naur]

Hi,

Working on a immediate mode fork of Shiny, I ran into this comment:

// We round up the ascent and descent separately, instead of asking for

// the metrics' height, since we quantize the baseline to the integer

// pixel grid. For example, if ascent and descent were both 3.2 pixels,

// then the naive height would be 6.4, which rounds up to 7, but we

// should really provide 8 pixels (= ceil(3.2) + ceil(3.2)) between

// each line to avoid overlap.

(https://github.com/golang/exp/blob/50c28f97489115b511c3104aafe83f148deb39a9/shiny/text/text.go#L151)

Is there a fundamental reason to quantize the baseline? The golang.org/x/image/font package offers (fixed point) subpixel accuracy, so why not use it? Is there a performance advantage or is it easier to cache pre-rendered text?

Finally, is the origin argument of node.Paint(Base) for the same reason? It seems to me it could be baked into the context's src2dst matrix.

 - elias

[David Crawshaw]

On Fri, Sep 15, 2017 at 7:35 AM, Elias Naur <elias...@gmail.com> wrote:
> Hi,
>
> Working on a immediate mode fork of Shiny,

Neat.

> I ran into this comment:
>
> // We round up the ascent and descent separately, instead of asking for
> // the metrics' height, since we quantize the baseline to the integer
> // pixel grid. For example, if ascent and descent were both 3.2 pixels,
> // then the naive height would be 6.4, which rounds up to 7, but we
> // should really provide 8 pixels (= ceil(3.2) + ceil(3.2)) between
> // each line to avoid overlap.
>
> (https://github.com/golang/exp/blob/50c28f97489115b511c3104aafe83f148deb39a9/shiny/text/text.go#L151)
>
> Is there a fundamental reason to quantize the baseline? The
> golang.org/x/image/font package offers (fixed point) subpixel accuracy, so
> why not use it? Is there a performance advantage or is it easier to cache
> pre-rendered text?

I have not been particularly interested in anything subpixel since
screens went high-DPI. As you say it greatly complicates caching, and
I cannot (visibly) see the advantage any more.

> Finally, is the origin argument of node.Paint(Base) for the same reason? It
> seems to me it could be baked into the context's src2dst matrix.

My motivation was always that integer pixels are simple and good
enough. Nigel could very well have a more thoughtful reason.

> - elias

[Nigel Tao]

On Sat, Sep 16, 2017 at 2:26 AM, David Crawshaw <craw...@golang.org> wrote:
> On Fri, Sep 15, 2017 at 7:35 AM, Elias Naur <elias...@gmail.com> wrote:
>> Is there a fundamental reason to quantize the baseline? The
>> golang.org/x/image/font package offers (fixed point) subpixel accuracy, so
>> why not use it? Is there a performance advantage or is it easier to cache
>> pre-rendered text?
>
> I have not been particularly interested in anything subpixel since
> screens went high-DPI. As you say it greatly complicates caching, and
> I cannot (visibly) see the advantage any more.

I think it's because I've always seen quantized baselines, even with
sub-pixel positioning. I suppose you could skip quantizing the
baseline, but it might look a little weird.

It's certainly easier to cache the glyphs if you quantize the
vertical. FWIW, the default Options type in
https://github.com/golang/freetype/blob/master/truetype/face.go
quantizes to 1 pixel vertically and 0.25 pixels horizontally.

>> Finally, is the origin argument of node.Paint(Base) for the same reason? It
>> seems to me it could be baked into the context's src2dst matrix.
>
> My motivation was always that integer pixels are simple and good
> enough. Nigel could very well have a more thoughtful reason.

The origin argument lets you paint 1 widget onto N tiles, for
accelerated scrolling of e.g. a text widget. It's hard to cut an image
into tiles along subpixels.