Currently, the PDF backend does not support image filters (since PDF
does not have that functionality), so it simply removes them. This is
causing Chrome print preview to render incorrectly (see bug). The fix
here is to fall back to a raster device for image filters, as we used
to do in Blink. The resulting bitmap will be drawn to the destination
device as a normal main-memory-backed bitmap.
Note: this change invalidates the PDF results of all GMs containing
image filters (since they'll actually be rendered).
BUG=422144
Review URL: https://codereview.chromium.org/644323006
Compute blob bounds when the client doesn't pass explicit run rects to
the builder. This allows us to remove a couple of internal workarounds.
R=reed@google.com,mtklein@google.com,bungeman@google.com
Review URL: https://codereview.chromium.org/654873003
Reason for revert:
A large number of GMs on Ubuntu12 are failing. The text layout on GPU is visibly different than that for 8888.
Original issue's description:
> Change drawText() to generate positions and send to drawPosText()
>
> The idea here is to have a central place that does layout for drawText(), and
> then always feed text through drawPosText(). This both makes all of the
> GrTextContexts consistent in drawText() output, and does a better job of
> stressing drawPosText().
>
> Because of the effect of matrices on hinting and approximation error, the
> generated text is not 100% identical to that produced by the raster pipeline.
>
> BUG=skia:2778
>
> Committed: https://skia.googlesource.com/skia/+/7851a56895c9c076f73a835a7dd51d3c6180c16fTBR=cdalton.nvidia@gmail.com,bungeman@google.com,reed@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:2778
Review URL: https://codereview.chromium.org/659993003
The idea here is to have a central place that does layout for drawText(), and
then always feed text through drawPosText(). This both makes all of the
GrTextContexts consistent in drawText() output, and does a better job of
stressing drawPosText().
Because of the effect of matrices on hinting and approximation error, the
generated text is not 100% identical to that produced by the raster pipeline.
BUG=skia:2778
Review URL: https://codereview.chromium.org/653133004
Reason for revert:
Crashing the Windows bots.
Original issue's description:
> Fix color emoji.
>
> Removes the GrMaskFormat and single atlas in GrTextStrike.
> Replaces it by storing the GrMaskFormat in each GrGlyph, and
> doing a lookup for the correct atlas based on that.
>
> Disables color glyph rendering in GrDistanceFieldTextContext
> for now.
>
> BUG=skia:2887
>
> Committed: https://skia.googlesource.com/skia/+/bc92163ddfe957ad6ffbb02ac40e0ba75ff82216TBR=robertphillips@google.com,bungeman@google.com,reed@google.com,bsalomon@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:2887
Review URL: https://codereview.chromium.org/640413004
Removes the GrMaskFormat and single atlas in GrTextStrike.
Replaces it by storing the GrMaskFormat in each GrGlyph, and
doing a lookup for the correct atlas based on that.
Disables color glyph rendering in GrDistanceFieldTextContext
for now.
BUG=skia:2887
Review URL: https://codereview.chromium.org/636183005
typeface. Loads the paths using the driver's glyph loading routines.
Refactors GrPathRange to accept a PathGenerator class that it uses to
lazily initialize its paths. The client code is no longer expected to
initialize the paths in a GrPathRange; instead it must provide a
PathGenerator* instance to createPathRange().
Adds a new createGlyphs() method to GrPathRendering that creates a
range of glyph paths, indexed by glyph id. GrPathRendering implements
createGlyphs() with a PathGenerator that loads glyph paths using the
skia frameworks. GrGLPathRendering uses glMemoryGlyphIndexArrayNV()
instead, when possible, to load the glyph paths.
Removes all GlyphPathRange logic from GrStencilAndCoverTextContext.
It instead uses createGlyphs().
BUG=skia:2939
R=bsalomon@google.com, jvanverth@google.com
Author: cdalton@nvidia.com
Review URL: https://codereview.chromium.org/563283004
