[SkPDFDevice] Enable pathops-based inverse fills

[SkPDFDevice] Enable pathops-based inverse fills

Keeping the old compile guard for clipping only.

BUG=skia:3749
R=halcanary@google.com,caryclark@google.com,reed@google.com

Committed: https://skia.googlesource.com/skia/+/632e92fc3fa99e6a78fcbc67d6da68d5bd8334c3

[f(malita), 2015-04-21 18:27:34]

Blink uses some inverse fills these days - do you think we can enable the
pathops PDF impl at this point?

[caryclark, 2015-04-21 18:49:06]

On 2015/04/21 18:27:34, f(malita) wrote:
> Blink uses some inverse fills these days - do you think we can enable the
> pathops PDF impl at this point?

Path Ops is getting really close to being done. Paths with cubics still fail to
generate the correct result some of the time -- I'm working on that now. After
that, I have a handful of outliers to investigate and resolve -- hopefully I can
say with confidence that it's ready for using everywhere in a few weeks.

That said, it should be fine to use within PDF's impl now -- I'm interested to
get more exercise of basic functionality.

[hal.canary, 2015-04-21 19:37:08]

But does it work?  If only I had pdf-to-gold up and running!  I think I'll take
a look at the output of this change tomorrow.

Also, which GMs use inverse paths?

[f(malita), 2015-04-21 20:12:08]

On 2015/04/21 19:37:08, Hal Canary wrote:
> But does it work?

Yes - I verified that it fixes the Chormium issue and also improves
GM:inverse_paths/PDF.


> Also, which GMs use inverse paths?

GM:inverse_paths is the one I was looking at, but I'm sure there are others that
will benefit.

[f(malita), 2015-04-21 20:15:48]

On 2015/04/21 20:12:08, f(malita) wrote:
> > Also, which GMs use inverse paths?
> 
> GM:inverse_paths is the one I was looking at, but I'm sure there are others
that
> will benefit.

A quick grep for kInverse (some of these may be clips and not path fills):

gm/complexclip3.cpp
gm/complexclip.cpp
gm/cubicpaths.cpp
gm/degeneratesegments.cpp
gm/emptypath.cpp
gm/filltypes.cpp
gm/filltypespersp.cpp
gm/inversepaths.cpp
gm/linepaths.cpp
gm/multipicturedraw.cpp
gm/pathopsinverse.cpp
gm/quadpaths.cpp

[reed1, 2015-04-21 22:16:53]

api lgtm

[hal.canary, 2015-04-22 21:52:06]

These gms render differently:

complexclip_aa_invert.pdf
complexclip_aa_layer_invert.pdf
complexclip_bw_invert.pdf
complexclip_bw_layer_invert.pdf
cubicclosepath.pdf
cubicpath.pdf
degeneratesegments.pdf
filltypes.pdf
inverse_paths.pdf
lineclosepath.pdf
linepath.pdf
pathinvfill.pdf
pathopsinverse.pdf
quadclosepath.pdf
quadpath.pdf

In no case do they render worse.  Most are closer to 8888.

LGTM

[f(malita), 2015-04-22 21:55:44]

On 2015/04/22 21:52:06, Hal Canary wrote:
> These gms render differently:
> 
> complexclip_aa_invert.pdf
> complexclip_aa_layer_invert.pdf
> complexclip_bw_invert.pdf
> complexclip_bw_layer_invert.pdf
> cubicclosepath.pdf
> cubicpath.pdf
> degeneratesegments.pdf
> filltypes.pdf
> inverse_paths.pdf
> lineclosepath.pdf
> linepath.pdf
> pathinvfill.pdf
> pathopsinverse.pdf
> quadclosepath.pdf
> quadpath.pdf
> 
> In no case do they render worse.  Most are closer to 8888.
> 
> LGTM

Thanks for checking, Hal!

[f(malita), 2015-04-22 21:55:48]

The CQ bit was checked by fmalita@chromium.org

[commit-bot: I haz the power, 2015-04-22 21:56:35]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1099953002/1

[commit-bot: I haz the power, 2015-04-22 22:02:09]

Committed patchset #1 (id:1) as
https://skia.googlesource.com/skia/+/632e92fc3fa99e6a78fcbc67d6da68d5bd8334c3