Bug 112717 – CSS reference (SVG) filters aren't rendered at the correct resolution with device scale, page scale or zooming

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: SVG

SVG filters aren't zoomed properly when used within CSS. Here are 3 cases to illustrate the problem, the first 2 cases work and the 3rd one fails.

Case 1 - CSS :

HTML code :
<img style="-webkit-filter:blur(10px)" src="resources/reference.png">

What happens:
We create a BlurFilterOperation object and scale its values in StyleResolver::createFilterOperations() using the zoomFactor which is applied when calling convertToFloatLength(). The behavior is good.

Case 2 - SVG :

HTML code :
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" width=160 height=300>
  <defs>
    <filter id="f1">
      <feGaussianBlur in="SourceGraphic" stdDeviation="10"/>
    </filter>
  </defs>
  <image x="0" y="0" width="160px" height="90px" xlink:href="resources/reference.png" filter="url(#f1)"/>
</svg>

What happens :
We create a SVGFilter object and use SVGFilter::applyHorizontalScale() and SVGFilter::applyVerticalScale() to apply the zoom factor. The behavior is good.

Case 3 - SVG within CSS :

HTML code :
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="0" height="0">
  <defs>
    <filter id="f1">
      <feGaussianBlur stdDeviation="10"/>
    </filter>
  </defs>
</svg>
<img style="-webkit-filter: url(#f1); filter: url(#f1);" src="resources/reference.png">

What happens :
We create a SVG Filter inside a CSS. This does not create a SVGFilter object, but creates the base class Filter object instead (It creates a REFERENCE filter operation within FilterEffectRenderer::build()). Since the base class functions Filter::applyHorizontalScale() and Filter::applyVerticalScale() have no information about the zoom, the blur kernel size is not scaled and the behavior is wrong.

Blur is just an example. All filters that require an adjustment for the zoom factor are most likely also wrong.

[Dirk Schulze]

Your observation is correct. Authors can define the resolution of the SVG Filter according to the spec. But this is not the only reason for setting m_filterResolution in Filter.h


Filtered elements can have transforms on it, which could increase the element size (transform="scale(2)"). The image for this element must be bigger to cover the bigger resolution. Both things, filter resolution and element resolution are set with:

    // Set the scale level in SVGFilter.
    filterData->filter->setFilterResolution(scale);

in RenderSVGResourceFilter (scale is  a FloatSize here).

Since CSS does not use RenderSVGResourceFilter, the CSS code must do this step on it's own. I assume that this is not the case at the moment.

[Dirk Schulze]

*** Bug 93471 has been marked as a duplicate of this bug. ***

[Simon Fraser (smfr)]

Tried to improve the title. Please fix if it's inaccurate.

[Stephen White]

(In reply to comment #2)
> *** Bug 93471 has been marked as a duplicate of this bug. ***

I don't think this is exactly the same problem as 93471, since this problem applies only to SVG filters within CSS, not the CSS shorthand filters.

CSS (shorthand) filters don't exhibit the offset problems Alexis describes.  They are Case 1 above.

[Said Abou-Hallawa]

Created attachment 462815 [details]
test case (open and zoom in)

[Said Abou-Hallawa]

I think this bug has been fixed a while ago.