[Webkit-unassigned] [Bug 144335] Applying a filter on an SVG element, which is larger than 4096 pixels, causes this element to be rendered shifted to the left

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=144335

--- Comment #4 from Said Abou-Hallawa <sabouhallawa at apple.com> ---
When applying a filter on an SVG element and one of the input effects of this element is the SourceGraphic, this is what happens to render the element and the applied filter:

1- An ImageBuffer is created with the size of this element. This ImageBuffer is called the sourceGraphicBuffer and it's created by calling SVGRenderingContext::createImageBuffer().
2- The GraphicContext of this image is transformed such that the render object can be drawn on the image without modifying its coordinates.
3- The GraphicContext of the paintInfo is switched to the created image.
4- The SVG render element is called to paint itself.
5- After finishing the drawing of the element, the FilterEffects are applied in RenderSVGResourceFilter::postApplyResource(). The FilterEffect inputs are passed as ImageBuffers and its output is also an ImageBuffer.
6- As an example, SourceGraphic::platformApplySoftware() has the sourceGraphicBuffer as the only input. All what it does is creating the result ImageBuffer and drawing the sourceGraphicBuffer to it.
7- The ImageBuffer of the lastEffect is drawImageBuffer on the painting GraphicContext in the same rectangle as the original SVG element.

The steps 1-4 are done almost the same way by the clipper and the masker. They both call SVGRenderingContext::clipToImageBuffer() to transfer the clipped sourceGraphicBuffer to the painting context.

For some reason, clamping code was added to SVGRenderingContext::createImageBuffer() such that the size of the image can't exceed 4096x4096 pixels. Because of this clamping we had to transform the GraphicContext so the drawing will be scaled down to the clamped ImageBuffer. The implementation was not complete for the following reasons:

-- The order of the transformation in SVGRenderingContext::createImageBuffer() is incorrect. Every time a transformation is applied, the following transformation has to use units in the current coordinates system. The order should be the following:
  a) Change the origin of the coordinate system of the ImageBuffer to match the painting GraphicContext. This is done by translate(-paintRect.x(), -paintRect.x()) since paintRect is in absolute coordinates.
  b) Change the coordinates system from absolute to local by concatCTM(absoluteTransform).
  c) Apply the clamping scaling.
So scaling down the coordinates system of the ImageBuffer was wrong because the paintRect is not in the clamped coordinates system.

-- The clamping transform was not propagated correctly to do the mapping from the clamped ImageBuffer to the painting GraphicContext. As an example look at RenderSVGResourceClipper::applyClippingToContext(). This function does the steps 1-4 above and then calls SVGRenderingContext::clipToImageBuffer(). The later function has no idea whether the clipperMaskImage is clamped or not. If it is clamped then it should used the clamping scaling in translating the ImageBufferRect. And also the painting GraphicContext has to scale up so the ImageBuffer is enlarged to fill the element painting rectangle. And this was not happening.

-- Although we clamp the ImageBuffer sourceGraphicBuffer, we do not take that into consideration when applying the FilterEffect. SourceGraphic::platformApplySoftware() just copy the clamped sourceGraphicBuffer without scaling it up so we end up having part of the SourceGraphic FilterEffect not drawn

-- We do not clamp any of the FilterEffect. See FilterEffect::createImageBufferResult(). In this function we call ImageBuffer::create() and pass the original size. So the clamping was done partially for the SourceGraphic but it was not done for any of the other FilterEffects.  

So it seems, this clamping code should be deleted since it has many defects and it's not complete. It has also the drawback of losing the SVG drawing quality because of scaling  the GraphicContext down and then scaling it up.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150502/8b8bbdc6/attachment.html>