Map light-source oBB-relative coordinates to the user-space of the filter

Map light-source oBB-relative coordinates to the user-space of the filter

The 'fePointLight' and 'feSpotLight' light-source elements for
'fe{Diffuse,Specular}Lighting' defines positions, and in the case of
the latter a 'look-at' point (implicit direction). When an SVG filter is
declared to use primitiveUnits=objectBoundingBox, these positions/points
needs to be mapped to the user-space of the filter.
This is achieved by adding a new method resolve3dPoint() to Filter, and
perform the coordinate space mapping when creating the various
LightSources.
Open-code SVGFELightElement::findLightSource() in it's sources to avoid
passing the Filter-instance around more than necessary.

BUG=176419
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=176499

[fs, 2014-06-18 16:24:31]

This is a bit ugly (IMO), but it seemed the least ugly of the non-shaving
options...

In some cases the primitive units are resolved on the SVG-side ([sub]regions)
and in some cases on the "platform"-side (effect parameters). It'd probably be
possible to move it to either side only (SVG-side likely easiest). That'd
probably allow getting rid of the apply{Horizontal,Vertical}Scale overrides on
SVGFilter (and maybe more.) If it sounds like a reasonable direction I can look
into it some more.

[Stephen White, 2014-06-18 17:21:27]

https://codereview.chromium.org/337903003/diff/1/Source/core/svg/graphics/fil...
File Source/core/svg/graphics/filters/SVGFilter.cpp (right):

https://codereview.chromium.org/337903003/diff/1/Source/core/svg/graphics/fil...
Source/core/svg/graphics/filters/SVGFilter.cpp:57: point.z() *
sqrtf(m_targetBoundingBox.size().diagonalLengthSquared() / 2));
Nit: the Z-scaling for CTM in Skia and Blink use the average of the X and Y
scales, rather than length/root2 (see FELighting::getTransform()
Sk*Light::transform()). I'm not sure if one or the other is more "spec correct",
but we should probably do the same thing in both cases. AFAICT it only makes a
difference in the x != y case.

[Stephen White, 2014-06-18 17:21:39]

Thanks so much for taking this on! I leave it up to you if you want to sync up
the treatment of z-scaling with CTM application, or leave it as-is.

LGTM

[fs, 2014-06-19 08:06:33]

On 2014/06/18 17:21:27, Stephen White wrote:
>
https://codereview.chromium.org/337903003/diff/1/Source/core/svg/graphics/fil...
> File Source/core/svg/graphics/filters/SVGFilter.cpp (right):
> 
>
https://codereview.chromium.org/337903003/diff/1/Source/core/svg/graphics/fil...
> Source/core/svg/graphics/filters/SVGFilter.cpp:57: point.z() *
> sqrtf(m_targetBoundingBox.size().diagonalLengthSquared() / 2));
> Nit: the Z-scaling for CTM in Skia and Blink use the average of the X and Y
> scales, rather than length/root2 (see FELighting::getTransform()
> Sk*Light::transform()). I'm not sure if one or the other is more "spec
correct",
> but we should probably do the same thing in both cases. AFAICT it only makes a
> difference in the x != y case.

This is per spec - see for instance 'z' in [1] which references [2]. I should've
made a note about this - sorry about that. (The "CTM-based scaling" is a
different matter, and not specified AFAIK.)

[1]
http://dev.w3.org/SVG/profiles/1.1F2/publish/filters.html#fePointLightElement
[2]
http://dev.w3.org/SVG/profiles/1.1F2/publish/coords.html#Units_viewport_perce...

[fs, 2014-06-19 08:06:56]

The CQ bit was checked by fs@opera.com

[commit-bot: I haz the power, 2014-06-19 08:07:36]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/fs@opera.com/337903003/1

[commit-bot: I haz the power, 2014-06-19 08:53:31]

Change committed as 176499

[Stephen White, 2014-07-14 21:02:59]

On 2014/06/19 08:53:31, I haz the power (commit-bot) wrote:
> Change committed as 176499

This change seems to have modified the results of this page:
http://letmespellitoutforyou.com/samples/svg/filter_terrain.svg

The Point and Spot cases don't seem to animate anymore. This differs from
Firefox result, where all 9 animate.  The whole page seems to be static on IE11;
not sure what's going on there.

fs@, could you take a look and see if you think we're doing the right thing
here?

[fs, 2014-07-15 11:02:34]

On 2014/07/14 21:02:59, Stephen White wrote:
> On 2014/06/19 08:53:31, I haz the power (commit-bot) wrote:
> > Change committed as 176499
> 
> This change seems to have modified the results of this page:
> http://letmespellitoutforyou.com/samples/svg/filter_terrain.svg
> 
> The Point and Spot cases don't seem to animate anymore. This differs from
> Firefox result, where all 9 animate.  The whole page seems to be static on
IE11;
> not sure what's going on there.
> 
> fs@, could you take a look and see if you think we're doing the right thing
> here?

Oopsie daisy... Seems this broke the animation update code-path (not resolving
there...). Filed http://crbug.com/393907, and am running a CL through the
try-bots...