Fix several issues with drawing text as paths.

Fix several issues with drawing text as paths.

SkPaint::setupForAsPaths currently does not scale the stroke width
(or miter) to match the scale. This produces incorrect results when
drawing outlined text as paths.

Currently, only SkDraw::drawPosText_asPaths is calling
SkPaint::setupForAsPaths. For consistency, the other "text as path"
methods on SkDraw should do so as well.

[bungeman-skia, 2013-07-27 15:23:54]

This initial change (Patch Set 1) updates SkDraw::drawTextOnPath, but
SkDraw::drawText_asPaths should also be updated. This does make things
consistent, but still has issues. At he very least the 'canonical text size' in
paint should be the em size (64 is a poor choice).

Moreover, paths are not necessarily freely scalable. The scaler context should
be queried if it's paths are scalable. If they are, then the current approach
works and saves time by caching the paths. If not, then the current matrix
should be passed to the path iterator to select the appropriate glyph cache. The
resulting paths will be in device space already (similar to producing glyph
masks), so device will need a 'drawScribble', where 'drawScribble' is to
drawPath what drawSprite is to drawBitmap. This sort of thing is needed for
properly drawing when the text is hinted, as well as for drawing pathed bitmap
fonts.

Note that this is incomplete and probably more of a bug report than an actual
proposed change. This was written mostly to understand and explain why the 'Text
On Path' slide in SampleApp sometimes acted oddly.

[bungeman-skia, 2013-07-27 15:27:44]

Also note that this may (or may not) have something to do with crbug.com/237181
.

[reed1, 2013-07-29 14:44:39]

Do we have GMs that exercise these code-paths?

https://codereview.chromium.org/20693003/diff/1/src/core/SkPaint.cpp
File src/core/SkPaint.cpp (right):

https://codereview.chromium.org/20693003/diff/1/src/core/SkPaint.cpp#newcode990
src/core/SkPaint.cpp:990: this->setStrokeWidth(fWidth / scale);
Can this be: setStrokeWIdth(fWidth * kCanonical / textSize) and avoid the 2nd
divide?

https://codereview.chromium.org/20693003/diff/1/src/core/SkPaint.cpp#newcode991
src/core/SkPaint.cpp:991: //this->setStrokeMiter(fMiterLimit / scale);
Do we need this line?

[bungeman-skia, 2013-07-29 14:54:18]

shadertext2 gm exercises this, as does the TextOnPath sample (in a more
interesting way).

https://codereview.chromium.org/20693003/diff/1/src/core/SkPaint.cpp
File src/core/SkPaint.cpp (right):

https://codereview.chromium.org/20693003/diff/1/src/core/SkPaint.cpp#newcode990
src/core/SkPaint.cpp:990: this->setStrokeWidth(fWidth / scale);
On 2013/07/29 14:44:39, reed1 wrote:
> Can this be: setStrokeWIdth(fWidth * kCanonical / textSize) and avoid the 2nd
> divide?

Sure, so long as its the same number, doesn't matter how we get there.

https://codereview.chromium.org/20693003/diff/1/src/core/SkPaint.cpp#newcode991
src/core/SkPaint.cpp:991: //this->setStrokeMiter(fMiterLimit / scale);
On 2013/07/29 14:44:39, reed1 wrote:
> Do we need this line?

Probably? The only reason it's commented out is that this creates crazy
artifacts in the shadertext2 gm. (The points on the 'A' get pointy.)

[bungeman-skia, 2014-05-22 15:06:25]

https://codereview.chromium.org/20693003/diff/1/src/core/SkPaint.cpp
File src/core/SkPaint.cpp (right):

https://codereview.chromium.org/20693003/diff/1/src/core/SkPaint.cpp#newcode991
src/core/SkPaint.cpp:991: //this->setStrokeMiter(fMiterLimit / scale);
On 2013/07/29 14:54:18, bungeman1 wrote:
> On 2013/07/29 14:44:39, reed1 wrote:
> > Do we need this line?
> 
> Probably? The only reason it's commented out is that this creates crazy
> artifacts in the shadertext2 gm. (The points on the 'A' get pointy.)

Mike pointed out to me that the miter limit is actually a ratio anyway, not a
hard value. As a result, this commented out line should be removed as it does
not need to scale.