Support underline and strikethrough painting in |drawPosText()| API.

Support underline and strikethrough painting in |drawPosText()| API.
Moves the drawing of the decorators from SkCanvas.cpp to SkDraw.cpp

[Steve VanDeBogart, 2011-10-31 17:03:32]

You would also need to call drawTextDecorations from the appropriate methods in
SkPDFDevice.cpp

[reed1, 2011-10-31 17:06:02]

agreed, I don't think we can take the patch as is, since it will break other
devices that don't rely on SkDraw's implementation of text drawing.

[reed1, 2011-10-31 17:06:37]

 brian to track gpu-device

[Alexei Svitkine, 2011-10-31 17:09:23]

Do they all call the same SkDraw1Glyph::Proc functions, or is that
also specific to SkDraw?

(If they share them, then perhaps the decorator functions could be
called by the proc functions...)

-Alexei

On Mon, Oct 31, 2011 at 1:06 PM,  <[email protected]> wrote:
>  brian to track gpu-device
>
> http://codereview.appspot.com/5319064/
>

[Steve VanDeBogart, 2011-10-31 17:11:07]

No, if you take a look, SkPDFDevice doesn't use the draw infrastructure aside
from extracting matrix and clip.

On 2011/10/31 17:09:23, Alexei Svitkine wrote:
> Do they all call the same SkDraw1Glyph::Proc functions, or is that
> also specific to SkDraw?
> 
> (If they share them, then perhaps the decorator functions could be
> called by the proc functions...)
> 
> -Alexei
> 
> On Mon, Oct 31, 2011 at 1:06 PM,  <mailto:[email protected]> wrote:
> >  brian to track gpu-device
> >
> > http://codereview.appspot.com/5319064/
> >

[bsalomon, 2011-10-31 17:52:39]

We should have a GM test that exercises the underline and strikethrough
decorations.

[Alexei Svitkine, 2011-11-01 14:40:31]

Thinking about this some more:

The reason I moved the decoration code to SkDraw.cpp was because
knowledge about the glyph extents was needed so that the code would
know what to underline. At the SkCanvas level, that information was
not available (without adding code to iterate the glyphs to SkCanvas
just to draw the decorators).

So I can see a few ways of solving this:

1. Modify the SkDevice's drawPosText() function signature to fill a
vector of glyph ranges which SkCanvas would then use to underline the
text
2. Modify the SkDevice's drawPosText() function signature to take a
callback param that will be called for each glyph or continuous glyph
range - the callback would then be used to underline the characters
3. Make SkCanvas do its own iteration of the glyphs in the same way
SkDraw::drawPosText() iterates them to draw the decorations - I'm not
sure this will actually be correct - would glyph extents be the same
for all device types?
4. Move the decoration drawing to a helper class and use it from the
different devices.

What approach would you find more appropriate here?

On Mon, Oct 31, 2011 at 1:52 PM,  <[email protected]> wrote:
> We should have a GM test that exercises the underline and strikethrough
> decorations.
>
> http://codereview.appspot.com/5319064/
>

[reed1, 2011-11-01 15:33:06]

I would like to remove underline/strikethru from the skia featureset. We already
have lots of problems with decorations today:

- overdraw, so they don't play well with xfermodes
- no control over height or thickness
- not extensible, (double-strike-thru, overline, etc.)
- they don't work with drawPosText or drawTextOnPath

I wonder if we can explore for a minute this idea. Can we remove them as a
canonical feature? If we did, what would be the minimum extra APIs (if any) we
would want to allow clients to do a good job of this themselves?

Or, are they absolutely required, and therefore we need to make it a priority to
fix the above list?