add more tests

add more tests

BUG=skia:
TBR=

Committed: https://skia.googlesource.com/skia/+/5fbb623099a6d0e0e72e7e230e75014fd64ae240

[reed1, 2015-06-23 21:28:46]

The CQ bit was checked by reed@google.com

[commit-bot: I haz the power, 2015-06-23 21:29:14]

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

[commit-bot: I haz the power, 2015-06-23 21:35:02]

Committed patchset #2 (id:20001) as
https://skia.googlesource.com/skia/+/5fbb623099a6d0e0e72e7e230e75014fd64ae240

[reed1, 2015-06-23 21:37:39]

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

[reed1, 2015-06-23 21:37:40]

This latest rev. addes explicit combos of clipping and croprects for
offsetimagefilter.

The last combo shows an offset equal to the width of the primtive, (offset to
the right).

In that combo, the croprect and clip are set to the dst position of the
primitive. I assumed nothing would draw, since the croprect should have
completely cropped-out the src, ... but it is drawing! Is this a bug?

My read of the spec:

‘x’, ‘y’, ‘width’ and ‘height’ act as a hard clip clipping rectangle on both the
filter primitive's input image(s) and the filter primitive result.

Is that the croprect should have "clipped" the src entirely out, so I didn't
expect anything to appear.

[robertphillips, 2015-06-24 16:23:53]

lgtm + dox requests

https://codereview.chromium.org/1201333002/diff/20001/gm/offsetimagefilter.cpp
File gm/offsetimagefilter.cpp (right):

https://codereview.chromium.org/1201333002/diff/20001/gm/offsetimagefilter.cp...
gm/offsetimagefilter.cpp:166: canvas->save();
// 0,0: rect draw - no offset
?

https://codereview.chromium.org/1201333002/diff/20001/gm/offsetimagefilter.cp...
gm/offsetimagefilter.cpp:168: 
// 1,0: offset rect draw
?

https://codereview.chromium.org/1201333002/diff/20001/gm/offsetimagefilter.cp...
gm/offsetimagefilter.cpp:171: 
// 2,0: offset rect draw with crop rect - 3/4 of the rect should be cropped
etc ?