Using the device scale factor for glyph positioning

Using the device scale factor for glyph positioning

Patch for initial discussion only. This seems to work correctly and have
the same effect as the patch for https://bugs.webkit.org/show_bug.cgi?id=94028 . The master bug is http://code.google.com/p/chromium/issues/detail?id=138101 .

behdad@ suggested that the changes in SkFontHost_FreeType::SkFontHost_FreeType() would work provided that we had access to the device scale factor. However, this constructor gets called on both the layout and rendering paths, and we only want to use the scale factor for the rendering path (otherwise the scale factor should be 1). Based on tracing the two code paths, I believe this patch demonstrates that the approach will work.

Note that the changes in https://codereview.appspot.com/6493048 should also be included in this CL (for some reason my src/ and include/ directories were in different repos so I had to upload these as separate CLs).

BUG=

[wjmaclean, 2012-08-28 21:00:15]

LGTM in general, no obvious red flags ...

https://codereview.appspot.com/6501050/diff/1/core/SkPaint.cpp
File core/SkPaint.cpp (right):

https://codereview.appspot.com/6501050/diff/1/core/SkPaint.cpp#newcode1862
core/SkPaint.cpp:1862: scaleFactor = SkScalarToFloat(deviceMatrix->getScaleX());
Maybe add a comment to explain why we're just considering getScaleX()?

[behdad, 2012-08-29 14:16:01]

LGTM in general.

[reed1, 2012-08-29 17:36:49]

The change seems to be: Have the hinted metrics ignore the device scale (which
is applied afterwards linearly). This means a caller cannot get the "best"
hinted metrics if they are zoomed/scaled.

We should not make this change to Skia.

Does this (below) give the desired results?

1. w[] = paint.getTextWidths(...)
2. canvas.scale(deviceScale);
3. foreach: w[i] /= deviceScale;
4. canvas.drawPosText(..., w[], paint)

[behdad, 2012-08-29 17:51:26]

On 2012/08/29 17:36:49, reed1 wrote:
> The change seems to be: Have the hinted metrics ignore the device scale (which
> is applied afterwards linearly). This means a caller cannot get the "best"
> hinted metrics if they are zoomed/scaled.
> 
> We should not make this change to Skia.
> 
> Does this (below) give the desired results?
> 
> 1. w[] = paint.getTextWidths(...)
> 2. canvas.scale(deviceScale);
> 3. foreach: w[i] /= deviceScale;
> 4. canvas.drawPosText(..., w[], paint)

That quite possibly will have the same bug that we are trying resolve.  I'm
putting screenshots and a doc together to justify this approach.  Stay tuned.

[reed1, 2012-08-29 17:53:13]

If that proves out, we will need a 3rd approach, as we can't change skia to
never give the composed hinted metrics, as this CL does.

[behdad, 2012-08-29 17:54:45]

On 2012/08/29 17:53:13, reed1 wrote:
> If that proves out, we will need a 3rd approach, as we can't change skia to
> never give the composed hinted metrics, as this CL does.

Humm?  I thought a scaleFactor of 1.0 would make the code behave as it currently
does?

[reed1, 2012-08-29 17:55:25]

On 2012/08/29 17:54:45, behdad wrote:
> On 2012/08/29 17:53:13, reed1 wrote:
> > If that proves out, we will need a 3rd approach, as we can't change skia to
> > never give the composed hinted metrics, as this CL does.
> 
> Humm?  I thought a scaleFactor of 1.0 would make the code behave as it
currently
> does?

If there is a scale on the matrix, we will not pass 1.0

[behdad, 2012-08-31 02:55:25]

On 2012/08/29 17:55:25, reed1 wrote:
> On 2012/08/29 17:54:45, behdad wrote:
> > On 2012/08/29 17:53:13, reed1 wrote:
> > > If that proves out, we will need a 3rd approach, as we can't change skia
to
> > > never give the composed hinted metrics, as this CL does.
> > 
> > Humm?  I thought a scaleFactor of 1.0 would make the code behave as it
> currently
> > does?
> 
> If there is a scale on the matrix, we will not pass 1.0

My bad.  I didn't notice how the patch works.  Terry is working on a proper
solution.

In the meantime, here's a document explaining what is to be achieved:

  http://go/high-dpi

[tdanderson, 2012-09-07 20:22:00]

On 2012/08/31 02:55:25, behdad wrote:
> On 2012/08/29 17:55:25, reed1 wrote:
> > On 2012/08/29 17:54:45, behdad wrote:
> > > On 2012/08/29 17:53:13, reed1 wrote:
> > > > If that proves out, we will need a 3rd approach, as we can't change skia
> to
> > > > never give the composed hinted metrics, as this CL does.
> > > 
> > > Humm?  I thought a scaleFactor of 1.0 would make the code behave as it
> > currently
> > > does?
> > 
> > If there is a scale on the matrix, we will not pass 1.0
> 
> My bad.  I didn't notice how the patch works.  Terry is working on a proper
> solution.
> 
> In the meantime, here's a document explaining what is to be achieved:
> 
>   http://go/high-dpi

The approach in this CL is no longer being pursued. See
https://codereview.appspot.com/6495089/ instead.