Fix image filters for PDF backend.

Fix image filters for PDF backend.

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
Committed: https://skia.googlesource.com/skia/+/b0e89dcc1d8c1c2f9f7ffb45e8609cdb4a68104b

[Stephen White, 2014-10-20 14:19:49]

senorblanco@chromium.org changed reviewers:
+ reed@google.com

[Stephen White, 2014-10-20 14:20:01]

reed@: PTAL. Thanks!

[reed1, 2014-10-20 18:37:26]

reed@google.com changed reviewers:
+ bsalomon@google.com, halcanary@google.com, robertphillips@google.com

[reed1, 2014-10-20 18:37:27]

This will mean we force all of the contents of that layer to be rasterized at
(effectively) screen-res, not printer res.

1. Are there classes of imagefilters that *can* be approximated in PS (e.g.
offset). Identifying those might allow us to keep native resolution (and
performance).

2. Can we try triggering this "raster device in a non-raster canvas" scenario in
other ways, to help test it w/o having to trigger PDF (which our tools do
relatively rarely)?

[Stephen White, 2014-10-20 18:47:37]

On 2014/10/20 18:37:27, reed1 wrote:
> This will mean we force all of the contents of that layer to be rasterized at
> (effectively) screen-res, not printer res.

Yep. Note that this is also how the old Blink code worked.

> 1. Are there classes of imagefilters that *can* be approximated in PS (e.g.
> offset). Identifying those might allow us to keep native resolution (and
> performance).

Yes, offset is probably doable. But rarely used. The most common ones
(currently)
are grayscale and blur. Since this is a regression in Chrome, I'd rather get
this
in now and worry about optimization later. Note that the old Blink code also
rasterized at screen res, so this change would effectively bring us back to
parity
with pre-M37.

> 2. Can we try triggering this "raster device in a non-raster canvas" scenario
in
> other ways, to help test it w/o having to trigger PDF (which our tools do
> relatively rarely)?

It looks like we keep PNGs of PDF results for the GMs for a lot of the bots.
That 
doesn't seem too rare. Or am I wrong about that?

I'm always open to other tests, though. I could write a unit test that creates a
mock filter, and check that its onFilterImage() gets called by SkPDFDevice.
How does that sound?

[Stephen White, 2014-10-20 19:07:45]

New patch up w/unit test for CPU-fallback; PTAL. Thanks!

[reed1, 2014-10-20 20:38:49]

Lets file a bug about want to do a better job of this [ sniff res? filters that
can be expressed in PS? etc. ] and reference that bug in the PDF file where we
create a raster device.

[reed1, 2014-10-20 20:39:30]

lgtm

[Stephen White, 2014-10-20 20:54:21]

On 2014/10/20 20:38:49, reed1 wrote:
> Lets file a bug about want to do a better job of this [ sniff res? filters
that
> can be expressed in PS? etc. ] and reference that bug in the PDF file where we
> create a raster device.

Good idea; done.

Thanks for your review!

[Stephen White, 2014-10-20 20:55:35]

The CQ bit was checked by senorblanco@chromium.org

[commit-bot: I haz the power, 2014-10-20 20:56:21]

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

[commit-bot: I haz the power, 2014-10-20 21:03:17]

Committed patchset #9 (id:160001) as b0e89dcc1d8c1c2f9f7ffb45e8609cdb4a68104b