OSX Text Rendering Parity with Skia (drawPosTextH)

[Corey Lucier]

I'm using the system typesetter on OSX and generating glyph positions for a given string.

I then use Skia to render alongside the native OSX Text View.

There are subtle differences in the glyph positions though, and the result doesn't exactly match what the system renders. (Assume for the sake of argument that I've dialed into the Core Text attributes identically for both the Skia and native text).

FWIW it's left aligned text and we're drawing with these paint attributes:

    paint->setAntiAlias(true);

    paint->setDevKernText(false);

    paint->setSubpixelText(true);

    paint->setHinting(SkPaint::kNo_Hinting);

We are using m_canvas->drawPosTextH to a raster buffer (non GPU mode).

Could it be simply that the floating to fixed conversion of each glyph position that Skia does in SkDraw::drawPosText ?

e.g.

SkFixed fx = SkScalarToFixed(tmsLoc.fX) + d1g.fHalfSampleX;

SkFixed fy = SkScalarToFixed(tmsLoc.fY) + d1g.fHalfSampleY;

[Ben Wagner]

Is it possible to get screen capture of the differences? How subtle is the difference? Skia discretizes subpixel to quarter pixel, while the TextView may end up with something different (maybe 1/6 pixel?). I'd expect we could easily be up to 1/8 of a pixel different here. Does it seem more than that?

--
You received this message because you are subscribed to the Google Groups "skia-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.
To post to this group, send email to skia-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/skia-discuss.
For more options, visit https://groups.google.com/d/optout.

[Corey Lucier]

Attached is an animated GIF.

What I was trying to do was figure a clean way of augmenting the position data before I feed to OSX such that it's a bit closer to what Skia is doing.

-C

[Corey Lucier]

Groups seems to have stripped the animation trying again with zip...

[Mike Klein]

I thought for a minute there you were trolling us. :)

On Wed, Jan 6, 2016 at 2:40 PM Corey Lucier <corey....@gmail.com> wrote:

Groups seems to have stripped the animation trying again with zip...

[Ben Wagner]

That's... not quite what I expected. I sure like where Skia put the glyphs as opposed to TextView. In the frame labeled TextView the 'Aa' are too close together (touching) and the spacing of the '3333' seems wrong (the kerning of the middle two seems lo leave extra space). They're both obviously doing subpixel positioned glyphs, so I'm not sure why these seem so dramatically different. I'm not sure what the quantization level of CoreText is anymore, I thought it was 1/6 but it might be 1/3. Depending on what you're doing, you could try CGContextSetAllowsFontSubpixelQuantization / CGContextSetShouldSubpixelQuantizeFonts and turn it off and see what difference that makes. I'm not sure if there is a higher level way to set that or not.

[Corey Lucier]

NSTextView seems to favor sharper glyph rendition ..so it adjusts positions accordingly to ensure they are all sharp, Skia's d and b tend to be a tad thicker in this string.

For whatever reason the quantization context apis don't seem to affect the result..will dig further. 

[Corey Lucier]

CGContextSetAllowsFontSubpixelQuantization(context, NO);

CGContextSetShouldSubpixelQuantizeFonts(context, NO);

Did the trick in terms of consistency... No chance of exposing a dial on the Skia side to allow us to match CG's quantization results?

-C

[Mike Reed]

I'm up for considering quantization experiments on our side. We already quantize (snap) Y coordinates when the text is horizontal...