On Sat, Sep 16, 2017 at 2:26 AM, David Crawshaw <craws...@golang.org> wrote: > On Fri, Sep 15, 2017 at 7:35 AM, Elias Naur <elias.n...@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. -- 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.
