Implement a computeFastBounds() traversal for SkImageFilter. This allows for correct culling of pri…

Implement a computeFastBounds() traversal for SkImageFilter.

This allows for correct culling of primitives which have image filters applied.

R=reed@google.com
BUG=skia:

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

[Stephen White, 2014-01-27 16:50:09]

PTAL. This is just the computeFastBounds() traversal for SkImageFilter, with the
AutoDrawLooper changes reverted.

[reed1, 2014-01-27 17:51:46]

Same question for out other bounds getters, but I wonder how we could test these
methods, to ensure we don't ever get a too-small area, and could therefore skip
drawing if we were clipped in an unlucky way...

lgtm w/ question

https://codereview.chromium.org/137423005/diff/1/include/core/SkImageFilter.h
File include/core/SkImageFilter.h (right):

https://codereview.chromium.org/137423005/diff/1/include/core/SkImageFilter.h...
include/core/SkImageFilter.h:146: // Default impl returns union of all input
bounds.
Does the default behavior always return a correct result? Are there filters that
must override this to avoid bugs?

[Stephen White, 2014-01-27 18:06:16]

On 2014/01/27 17:51:46, reed1 wrote:
> Same question for out other bounds getters, but I wonder how we could test
these
> methods, to ensure we don't ever get a too-small area, and could therefore
skip
> drawing if we were clipped in an unlucky way...

I can't think of a useful unit test. We could definitely add some GMs. However,
the results will be invalidated by upcoming changes (where we clip against
inflated bounds via onFilterBounds()), so I'd prefer to land them when the
results are correct.

> lgtm w/ question
> 
> https://codereview.chromium.org/137423005/diff/1/include/core/SkImageFilter.h
> File include/core/SkImageFilter.h (right):
> 
>
https://codereview.chromium.org/137423005/diff/1/include/core/SkImageFilter.h...
> include/core/SkImageFilter.h:146: // Default impl returns union of all input
> bounds.
> Does the default behavior always return a correct result? Are there filters
that
> must override this to avoid bugs?

The default will be correct for non-pixel moving filters (e.g.,
SkColorFilterImageFilter, SkMergeImageFilter, SkComposeImageFilter, etc).  It
will be wrong for pixel-moving filters. I'd prefer to keep the simple (and more
common) case simple.

(Note that *all* pixel-moving filters were being incorrectly culled prior to
this change, so this isn't a regression.)

[Stephen White, 2014-01-27 21:03:28]

Committed patchset #2 manually as r13207 (presubmit successful).