On Fri, Sep 15, 2017 at 7:35 AM, Elias Naur <elias.n...@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 -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
