Implement a generic matrix transform image filter.

Implement a generic matrix transform image filter.

This will be used in Blink to accommodate matrices that contain
rotation or shearing. This is a generalization of SkResizeImageFilter,
so I've replaced all uses of SkResizeImageFilter in Skia. (It might be
easier to review by diffing it with SkResizeImageFilter, too.)

R=reed@google.com

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

[Stephen White, 2014-03-25 15:05:14]

reed@: PTAL. Thanks!

[reed1, 2014-03-25 16:04:04]

https://codereview.chromium.org/211103006/diff/10012/include/effects/SkTransf...
File include/effects/SkTransformImageFilter.h (right):

https://codereview.chromium.org/211103006/diff/10012/include/effects/SkTransf...
include/effects/SkTransformImageFilter.h:22: class SK_API SkTransformImageFilter
: public SkImageFilter {
bikeshed: SkMatrixImageFilter -- since it takes a matrix and skia talks in terms
of matrices, not transforms.

[Stephen White, 2014-03-25 16:17:24]

On 2014/03/25 16:04:04, reed1 wrote:
>
https://codereview.chromium.org/211103006/diff/10012/include/effects/SkTransf...
> File include/effects/SkTransformImageFilter.h (right):
> 
>
https://codereview.chromium.org/211103006/diff/10012/include/effects/SkTransf...
> include/effects/SkTransformImageFilter.h:22: class SK_API
SkTransformImageFilter
> : public SkImageFilter {
> bikeshed: SkMatrixImageFilter -- since it takes a matrix and skia talks in
terms
> of matrices, not transforms.

Good idea -- that was my second choice. :) 

I thought it might confuse people WRT SkMatrixConvolutionImageFilter, but
perhaps that's not as big a deal as I think it is.

[Stephen White, 2014-03-25 16:45:19]

On 2014/03/25 16:04:04, reed1 wrote:
>
https://codereview.chromium.org/211103006/diff/10012/include/effects/SkTransf...
> File include/effects/SkTransformImageFilter.h (right):
> 
>
https://codereview.chromium.org/211103006/diff/10012/include/effects/SkTransf...
> include/effects/SkTransformImageFilter.h:22: class SK_API
SkTransformImageFilter
> : public SkImageFilter {
> bikeshed: SkMatrixImageFilter -- since it takes a matrix and skia talks in
terms
> of matrices, not transforms.

Done.

[reed1, 2014-03-25 17:09:32]

lgtm

[Stephen White, 2014-03-25 17:35:16]

Committed patchset #5 manually as r13941 (presubmit successful).

[krit, 2014-03-26 06:22:58]

We had a similar approach in WebKit where we just take scaling into account and
applied shearing and rotation later after the filter operation. The main problem
in WebKit: We just looked up to the root SVG element.We would not recognize CTM
changes by any root HTML element.

Also, how do you handle 3D transforms? Even if not implemented in SVG, HTML can
have 3D transforms applied to pretty much every element. Do you take these into
account? If yes, how?

[Stephen White, 2014-03-26 13:13:03]

On 2014/03/26 06:22:58, krit wrote:
> We had a similar approach in WebKit where we just take scaling into account
and
> applied shearing and rotation later after the filter operation. The main
problem
> in WebKit: We just looked up to the root SVG element.We would not recognize
CTM
> changes by any root HTML element.
> 
> Also, how do you handle 3D transforms? Even if not implemented in SVG, HTML
can
> have 3D transforms applied to pretty much every element. Do you take these
into
> account? If yes, how?

No, AFAIK the accumulation of transforms stops at the SVG root. While Skia
actually 
does support perspective matrices, so we could apply them if desired, applying
them
post-filter is likely the correct behaviour anyway. On the CSS side, if you want
to 
blur-then-transform, you apply filter: and transform: to the same element. If
you want 
to transform-then-blur, you apply the transform: to a parent element, and
filter: to the 
child. So both options are available. In neither case do the transforms directly
affect
the filter parameters.

I actually find it a bit odd that SVG automatically applies shearing and
rotation transforms to filters
at all. But that seems to be the spec behaviour.

[krit, 2014-03-26 14:24:29]

On 2014/03/26 13:13:03, Stephen White wrote:
> On 2014/03/26 06:22:58, krit wrote:
> > We had a similar approach in WebKit where we just take scaling into account
> and
> > applied shearing and rotation later after the filter operation. The main
> problem
> > in WebKit: We just looked up to the root SVG element.We would not recognize
> CTM
> > changes by any root HTML element.
> > 
> > Also, how do you handle 3D transforms? Even if not implemented in SVG, HTML
> can
> > have 3D transforms applied to pretty much every element. Do you take these
> into
> > account? If yes, how?
> 
> No, AFAIK the accumulation of transforms stops at the SVG root.

So the same problem as in WebKit still?

> While Skia
> actually 
> does support perspective matrices, so we could apply them if desired, applying
> them
> post-filter is likely the correct behaviour anyway.

No, filters need to be pixel perfect. That means you need to take care of the
elements own transform as well.

> On the CSS side, if you want
> to 
> blur-then-transform, you apply filter: and transform: to the same element.

Oh, I got you. You mean to get the rotation of the blur filter.

> If
> you want 
> to transform-then-blur, you apply the transform: to a parent element, and
> filter: to the 
> child. So both options are available. In neither case do the transforms
directly
> affect
> the filter parameters.
> 
> I actually find it a bit odd that SVG automatically applies shearing and
> rotation transforms to filters
> at all. But that seems to be the spec behaviour.

There has been request to let filters operate in a predefined coordinate space
or simply the root element space. This would allow you effects of rotating
elements where the shadow stays in the same direction. This will likely be a
theme for the next level of Filter Effects. This is what Flash does and many
game developers rely on.