Unify content transformation calculations for SVG clip paths

Unify content transformation calculations for SVG clip paths

This patch unifies the various content transformation calculations
into "LayoutSVGResourceClipper::calculateContentTransformation(...)".
This refactoring changes how transformed clip paths are applied to
other transformed clip paths with userSpaceOnUse. With this patch we
now match Gecko on the new test, though all implementations disagree
in this area (IE11, Presto, WebKit) and the spec [2] is vague.

[1] transformed-clip-in-transformed-clip.html
[2] http://dev.w3.org/fxtf/css-masking-1/#elementdef-clippath

BUG=500713

[pdr., 2015-06-16 06:24:42]

pdr@chromium.org changed reviewers:
+ fs@opera.com

[fs, 2015-06-16 09:30:15]

> With this patch we now match Gecko on the new test, though all implementations
disagree
> in this area (IE11, Presto, WebKit) and the spec [2] is vague.

Very vague indeed... I kind of would have expected the order(s) to be:

bboxTransform [or zoom] * 'transform'

which I believe would be consistent with oBB/uSOU treatment for paint servers.
Do we have test for the non-SVG effectiveZoom case? (I suspect that case is
pretty buggy though, but...)

https://codereview.chromium.org/1174393003/diff/20001/LayoutTests/svg/clip-pa...
File LayoutTests/svg/clip-path/transformed-clip-in-transformed-clip.html
(right):

https://codereview.chromium.org/1174393003/diff/20001/LayoutTests/svg/clip-pa...
LayoutTests/svg/clip-path/transformed-clip-in-transformed-clip.html:3: * {
Why do we need/want this?

https://codereview.chromium.org/1174393003/diff/20001/LayoutTests/svg/clip-pa...
LayoutTests/svg/clip-path/transformed-clip-in-transformed-clip.html:8: <svg
xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
width="300" height="300">
Whole lotta namespace declarations... (that isn't needed.)

https://codereview.chromium.org/1174393003/diff/20001/Source/core/layout/svg/...
File Source/core/layout/svg/LayoutSVGResourceClipper.cpp (left):

https://codereview.chromium.org/1174393003/diff/20001/Source/core/layout/svg/...
Source/core/layout/svg/LayoutSVGResourceClipper.cpp:224: if
(!animatedLocalTransform.isInvertible())
This got dropped.

https://codereview.chromium.org/1174393003/diff/20001/Source/core/layout/svg/...
File Source/core/layout/svg/LayoutSVGResourceClipper.cpp (right):

https://codereview.chromium.org/1174393003/diff/20001/Source/core/layout/svg/...
Source/core/layout/svg/LayoutSVGResourceClipper.cpp:69: AffineTransform
LayoutSVGResourceClipper::calculateContentTransformation(const LayoutObject*
target, const FloatRect& targetBoundingBox)
const?

https://codereview.chromium.org/1174393003/diff/20001/Source/core/layout/svg/...
Source/core/layout/svg/LayoutSVGResourceClipper.cpp:77:
transform.scale(style()->effectiveZoom());
Shouldn't this apply before 'transform'?

https://codereview.chromium.org/1174393003/diff/20001/Source/core/layout/svg/...
Source/core/layout/svg/LayoutSVGResourceClipper.cpp:213: m_clipBoundaries =
contentTransformation.mapRect(m_clipBoundaries);
This makes m_clipBoundaries depend on a certain client - the previous
formulation was only dependent on the clip path itself. Maybe just sink this
part out of the function, and let m_clipBoundaries be in the local coordinate
space of the clipPath instead?

https://codereview.chromium.org/1174393003/diff/20001/Source/core/layout/svg/...
Source/core/layout/svg/LayoutSVGResourceClipper.cpp:223:
contentTransformation.inverse().mapPoint(point);
point = ...