Fix dst bound reported by SkTileImageFilter

Fix dst bound reported by SkTileImageFilter

In the example from the bug we had the filter DAG:

color filter (table)
    0: xfermode filter (arith)
        0: tile filter [0,80,34,114] -> [0,80,800,480]
             0: color filter (table)
                 0: bitmap src 34x34 -> [0,80,34,114]
        1: color filter (table)
             0: picture filter [0, 80, 800, 480]

computeFastBounds was coming out of the DAG with a bound of [0,80,34,114] which didn't represent the pixels that would be drawn.

This CL updates SkTileImageFilter to correctly set the bound for the pixels it will hit.

BUG=493783
Committed: https://skia.googlesource.com/skia/+/05be93bbdf09576f7903130e3b106b0a8c7c4b4e

Committed: https://skia.googlesource.com/skia/+/0be685755f942baea26c66a87226b569fc17e960

Committed: https://skia.googlesource.com/skia/+/c3176aa5e578cc64a2534a9ddac2fec5ab6d8d77

[robertphillips, 2015-06-02 14:58:12]

robertphillips@google.com changed reviewers:
+ reed@google.com, senorblanco@google.com

[reed1, 2015-06-02 15:33:11]

Stephen, how can we update the dox for the Tile filter?

e.g. what *phase* is the src-rect in when it appears in the dst-rect? (e.g. does
it start at dst.left/dst.top?)

[reed1, 2015-06-02 15:33:29]

lgtm

[Stephen White, 2015-06-02 17:22:56]

On 2015/06/02 15:33:11, reed1 wrote:
> Stephen, how can we update the dox for the Tile filter?
> 
> e.g. what *phase* is the src-rect in when it appears in the dst-rect? (e.g.
does
> it start at dst.left/dst.top?)

Yeah, I think the phase is always 0, 0 at dstRect origin. The (CTM-transformed)
srcRect is used to do an extractSubset() of the filter's input bitmap, but is
then drawn wherever the dstRect is drawn using an SkBitmapShader (which I
believe uses dest rect origin for the bitmap origin). srcRect isn't used beyond
the initial extractSubset().

The srcOffset trickery is to preserve any *upstream* cropping that might occur,
but is unaffected by srcRect IIRC.

(Note that the dest rect is essentially the filter's crop rect, or the filter
region if no crop rect is specified. It was probably written before crop rects
existed. If we can manage to integrate the filter region into crop rect (as part
of eliminating the required bounds to saveLayer()), we should be able to get rid
of SkTileImageFilter's dstRect and just use its crop rect instead.)

[Stephen White, 2015-06-02 17:23:45]

Fix LGTM BTW. Thanks for tracking this down.

[robertphillips, 2015-06-02 17:25:11]

The CQ bit was checked by robertphillips@google.com to run a CQ dry run

[robertphillips, 2015-06-02 17:25:11]

The patchset sent to the CQ was uploaded after l-g-t-m from reed@google.com
Link to the patchset: https://codereview.chromium.org/1152553006/#ps40001
(title: "clean up")

[commit-bot: I haz the power, 2015-06-02 17:25:43]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1152553006/40001

[Stephen White, 2015-06-02 17:27:24]

senorblanco@chromium.org changed reviewers:
+ senorblanco@chromium.org

[Stephen White, 2015-06-02 17:27:25]

https://codereview.chromium.org/1152553006/diff/40001/gm/bigtileimagefilter.cpp
File gm/bigtileimagefilter.cpp (right):

https://codereview.chromium.org/1152553006/diff/40001/gm/bigtileimagefilter.c...
gm/bigtileimagefilter.cpp:23: return SkString("bigtileimagefilter");
BTW, if you wanted to consider using a unit test instead of a GM (to reduce the
number of baselines we need), take a look at ImageFilterDrawMatrixBBH, in
tests/ImageFilterTest.cpp. You might be able to copy/modify that to suit your
needs.

[commit-bot: I haz the power, 2015-06-02 17:30:51]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-06-02 17:30:52]

Dry run: This issue passed the CQ dry run.

[robertphillips, 2015-06-02 17:51:26]

The CQ bit was checked by robertphillips@google.com

[commit-bot: I haz the power, 2015-06-02 17:51:50]

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

[commit-bot: I haz the power, 2015-06-02 17:52:46]

Committed patchset #3 (id:40001) as
https://skia.googlesource.com/skia/+/05be93bbdf09576f7903130e3b106b0a8c7c4b4e

[robertphillips, 2015-06-02 17:56:59]

A revert of this CL (patchset #3 id:40001) has been created in
https://codereview.chromium.org/1143083006/ by robertphillips@google.com.

The reason for reverting is: breaking tests.

[robertphillips, 2015-06-04 13:48:05]

The CQ bit was checked by robertphillips@google.com

[commit-bot: I haz the power, 2015-06-04 13:48:17]

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

[commit-bot: I haz the power, 2015-06-04 13:53:40]

Committed patchset #3 (id:40001) as
https://skia.googlesource.com/skia/+/0be685755f942baea26c66a87226b569fc17e960

[robertphillips, 2015-06-04 15:27:02]

posthumous lgtm + a question

[robertphillips, 2015-06-04 15:27:54]

Ooops - wrong CL.

[robertphillips, 2015-06-04 18:15:02]

A revert of this CL (patchset #3 id:40001) has been created in
https://codereview.chromium.org/1156583004/ by robertphillips@google.com.

The reason for reverting is: Blink.

[Stephen White, 2015-06-10 17:59:00]

On 2015/06/04 18:15:02, robertphillips wrote:
> The reason for reverting is: Blink.

Rob, when you have time, could you elaborate a bit? Happy to help debug
something Blink-side if it would help.

[robertphillips, 2015-06-15 16:27:52]

The majority of this was landed separately as:
https://codereview.chromium.org/1169713003/ (Add bigtileimagefilter GM &
improvements to toString)

[robertphillips, 2015-06-16 16:10:01]

PTAL

The first version of the fix addressed the case where we had a
PictureImageFilter as a source. This, unfortunately didn't work when the
saveLayer itself was the source. The new patch handles both cases (somewhat
poorly).

[Stephen White, 2015-06-16 16:12:39]

On 2015/06/16 16:10:01, robertphillips wrote:
> PTAL
> 
> The first version of the fix addressed the case where we had a
> PictureImageFilter as a source. This, unfortunately didn't work when the
> saveLayer itself was the source. The new patch handles both cases (somewhat
> poorly).

LGTM

[robertphillips, 2015-06-16 16:16:59]

The CQ bit was checked by robertphillips@google.com to run a CQ dry run

[robertphillips, 2015-06-16 16:16:59]

The patchset sent to the CQ was uploaded after l-g-t-m from reed@google.com
Link to the patchset: https://codereview.chromium.org/1152553006/#ps120001
(title: "Fix line wraps")

[commit-bot: I haz the power, 2015-06-16 16:17:05]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1152553006/120001

[commit-bot: I haz the power, 2015-06-16 16:22:03]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-06-16 16:22:04]

Dry run: This issue passed the CQ dry run.

[robertphillips, 2015-06-16 16:44:12]

The CQ bit was checked by robertphillips@google.com

[commit-bot: I haz the power, 2015-06-16 16:44:21]

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

[commit-bot: I haz the power, 2015-06-16 16:44:59]

Committed patchset #7 (id:120001) as
https://skia.googlesource.com/skia/+/c3176aa5e578cc64a2534a9ddac2fec5ab6d8d77