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

Source/core/svg/graphics/filters/SVGFilter.cpp

Index: Source/core/svg/graphics/filters/SVGFilter.cpp
diff --git a/Source/core/svg/graphics/filters/SVGFilter.cpp b/Source/core/svg/graphics/filters/SVGFilter.cpp
index bd6fefd724e263b57a8713cd4faa6c8388f3f28f..5a3ae4590edb573a27237c6e95e96d8df0f27376 100644
--- a/Source/core/svg/graphics/filters/SVGFilter.cpp
+++ b/Source/core/svg/graphics/filters/SVGFilter.cpp
@@ -48,6 +48,15 @@ float SVGFilter::applyVerticalScale(float value) const
     return Filter::applyVerticalScale(value);
 }
 
+FloatPoint3D SVGFilter::resolve3dPoint(const FloatPoint3D& point) const
+{
+    if (!m_effectBBoxMode)
+        return point;
+    return FloatPoint3D(point.x() * m_targetBoundingBox.width() + m_targetBoundingBox.x(),
+        point.y() * m_targetBoundingBox.height() + m_targetBoundingBox.y(),
+        point.z() * sqrtf(m_targetBoundingBox.size().diagonalLengthSquared() / 2));

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

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.

+}
+
 PassRefPtr<SVGFilter> SVGFilter::create(const AffineTransform& absoluteTransform, const IntRect& absoluteSourceDrawingRegion, const FloatRect& targetBoundingBox, const FloatRect& filterRegion, bool effectBBoxMode)
 {
     return adoptRef(new SVGFilter(absoluteTransform, absoluteSourceDrawingRegion, targetBoundingBox, filterRegion, effectBBoxMode));