Implement bounds traversals for tile and matrix convolution filters.

Implement bounds traversals for tile and matrix convolution filters.

Add a new GM that exercises tiled drawing all pixel-moving filters
(and some non-pixel-moving ones) and compares it against non-tiled
drawing of the same filters. Fixing this test revealed that tile and
matrix convolution filters had no onFilterBounds() traversals
(test-driven development FTW). Tile requires (conservatively) the
bounds to include the whole source rect, since it may end up in the
result. Matrix convolution requires the bounds to be offset by the
kernel size and target.

R=reed@google.com
BUG=skia:

Committed: https://code.google.com/p/skia/source/detail?r=14432

[Stephen White, 2014-04-29 14:58:15]

reed@: PTAL. Thanks!

[reed1, 2014-04-29 15:01:12]

QQ -- can we make a change to the app (GM, DM) so that we can test *all* gms
tiled, and compare those results to non-tiled?

[mtklein, 2014-04-29 15:04:33]

On 2014/04/29 15:01:12, reed1 wrote:
> QQ -- can we make a change to the app (GM, DM) so that we can test *all* gms
> tiled, and compare those results to non-tiled?

Unless I misunderstand the question, I think --tileGrid does this for DM.  It's
disabled by default because ~50% of GMs draw at least one pixel wrong.

[Stephen White, 2014-04-29 15:05:04]

On 2014/04/29 15:01:12, reed1 wrote:
> QQ -- can we make a change to the app (GM, DM) so that we can test *all* gms
> tiled, and compare those results to non-tiled?

+mtklein, +epoger

I'm not sure that the pixels are guaranteed to match exactly for all Skia paths.
I think we ran into that issue in the tilegrid/rtree tests, and they currently
don't run with exact pixel checking for that reason.

They happen to work for all image filters, which is why I'm testing those here.

[reed1, 2014-04-29 15:08:41]

On 2014/04/29 15:05:04, Stephen White wrote:
> On 2014/04/29 15:01:12, reed1 wrote:
> > QQ -- can we make a change to the app (GM, DM) so that we can test *all* gms
> > tiled, and compare those results to non-tiled?
> 
> +mtklein, +epoger
> 
> I'm not sure that the pixels are guaranteed to match exactly for all Skia
paths.
> I think we ran into that issue in the tilegrid/rtree tests, and they currently
> don't run with exact pixel checking for that reason.
> 
> They happen to work for all image filters, which is why I'm testing those
here.

Hmmm, so how can we move forward on the larger solution? What if we added a flag
so that a given GM could opt in or out of tilieGrid perfectness? Would that
support imagefilter testing? If so, it might be a better way to push the entire
project forward...

[Stephen White, 2014-04-29 15:14:26]

On 2014/04/29 15:08:41, reed1 wrote:
> On 2014/04/29 15:05:04, Stephen White wrote:
> > On 2014/04/29 15:01:12, reed1 wrote:
> > > QQ -- can we make a change to the app (GM, DM) so that we can test *all*
gms
> > > tiled, and compare those results to non-tiled?
> > 
> > +mtklein, +epoger
> > 
> > I'm not sure that the pixels are guaranteed to match exactly for all Skia
> paths.
> > I think we ran into that issue in the tilegrid/rtree tests, and they
currently
> > don't run with exact pixel checking for that reason.
> > 
> > They happen to work for all image filters, which is why I'm testing those
> here.
> 
> Hmmm, so how can we move forward on the larger solution? What if we added a
flag
> so that a given GM could opt in or out of tilieGrid perfectness? Would that
> support imagefilter testing? If so, it might be a better way to push the
entire
> project forward...

I've filed https://code.google.com/p/skia/issues/detail?id=2477 for that work.

I think having a unit test here is a good idea regardless, since unlike the GMs
which contain
many filters and other moving parts, these tests can pinpoint exactly which
filter regressed.

[reed1, 2014-04-29 15:15:05]

lgtm

[Stephen White, 2014-04-29 15:20:44]

Committed patchset #1 manually as r14432 (presubmit successful).