Bug 148221 – Using the filter functional notation for background images results in wrong background-size rendering

• Component: CSS
• Status: RESOLVED FIXED

[thatemil]

When using the filter(<image>, <filter-list>) notation for loading a background-image, the background-size property is interpreted incorrectly.

Description:
The rectangle where the background is supposed to be drawn appears to be sized correctly, but inside that rectangle the actual pixels remain at the intrinsic size of the source image. In the demo linked below, the source image is 30px by 16px, and should be resized to 100px by 100px. As you can see in the demo, the image remains at 30x16, but the background tile is 100x100, causing the background tiles to leave transparent gaps. Any background-size measurement or filter combination seems to exhibit this bug.

Expected outcome: background-image should be stretched to 100x100 tiles, covering the element.

Tested on build r188682

Demo: http://jsbin.com/lodene/8/edit

[Simon Fraser (smfr)]

I'm confused. I didn't think we supported filter(<image>, <filter-list>).

[thatemil]

Well, confusion or no, the filter seems to work fine on the background image (I even tried animating it), it's just the sizing bit that doesn't seem to work. :-)

[Simon Fraser (smfr)]

Ah I see, it was -webkit-filter() until https://trac.webkit.org/changeset/188647.

Yes, this looks like a bug. We're not rendering the filtered output with the correct background-size.

[Radar WebKit Bug Importer]

<rdar://problem/22379518>

[zalan]

genererate filter image ignores the size argument when it copies the source to the destination.    

diff --git a/Source/WebCore/css/CSSFilterImageValue.cpp b/Source/WebCore/css/CSSFilterImageValue.cpp
index 5d80331..41de312 100644
--- a/Source/WebCore/css/CSSFilterImageValue.cpp
+++ b/Source/WebCore/css/CSSFilterImageValue.cpp
@@ -123,7 +123,7 @@ RefPtr<Image> CSSFilterImageValue::image(RenderElement* renderer, const FloatSiz
     std::unique_ptr<ImageBuffer> texture = ImageBuffer::create(size);
     if (!texture)
         return Image::nullImage();
-    texture->context()->drawImage(image, ColorSpaceDeviceRGB, IntPoint());
+    texture->context()->drawImage(image, ColorSpaceDeviceRGB, FloatRect(FloatPoint(0, 0), size));
 
     RefPtr<FilterEffectRenderer> filterRenderer = FilterEffectRenderer::create();
     filterRenderer->setSourceImage(WTF::move(texture));

[zalan]

Created attachment 259744 [details]
Patch

[Daniel Bates]

Comment on attachment 259744 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=259744&action=review

This looks sane to me.

> Source/WebCore/ChangeLog:10
> +        When the size is ignored, we end up paining the image with its native size while the filter

paining => painting

> LayoutTests/ChangeLog:10
> +        When the size is ignored, we end up paining the image with its native size while the filter

Ditto.

[Daniel Bates]

Comment on attachment 259744 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=259744&action=review

> LayoutTests/fast/filter-image/background-filter-image-expected.html:17
> +

Is this empty line necessary?

[zalan]

Created attachment 259882 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 259882 [details]
Patch

Clearing flags on attachment: 259882

Committed r188935: <http://trac.webkit.org/changeset/188935>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.