RESOLVED FIXED 68664
<feImage> referencing an <image> via xlink:href doesn't display correctly
https://bugs.webkit.org/show_bug.cgi?id=68664
Summary <feImage> referencing an <image> via xlink:href doesn't display correctly
Tim Horton
Reported 2011-09-22 17:04:38 PDT
Created attachment 108422 [details] repro Open the attached SVG in a WebKit browser and Opera. Note how the <feImage> that references an <image> doesn't render, while the <feImage> which directly references an image does. This breaks some of the "SVG Wow!" filters demos.
Attachments
repro (218.44 KB, application/zip)
2011-09-22 17:04 PDT, Tim Horton
no flags
assert repro (480 bytes, image/svg+xml)
2011-09-23 16:34 PDT, Tim Horton
no flags
smaller repro (218.71 KB, application/zip)
2011-09-26 17:24 PDT, Tim Horton
no flags
Radar WebKit Bug Importer
Comment 1 2011-09-22 17:05:21 PDT
Tim Horton
Comment 2 2011-09-22 17:06:06 PDT
(In reply to comment #0) > Note how the <feImage> that references an <image> doesn't render, while the <feImage> which directly references an image does. "directly references an image does" means an image *file*, I left that quite ambiguous.
Dirk Schulze
Comment 3 2011-09-22 22:12:31 PDT
Could be a problem of <image> which does not correctly rerender and does not invalidate the filter. I expect that the image was loaded after creating the filter.
Tim Horton
Comment 4 2011-09-23 16:33:50 PDT
Actually, it looks like the computation of targetRect in SVGFEImageElement::build is wrong. Attaching another SVG which causes an assertion failure related to this (I removed the width/height on the <image>, so SVGFEImageElement::build is trying to create a 0x0 image for whatever reason, and failing and dying).
Tim Horton
Comment 5 2011-09-23 16:34:14 PDT
Created attachment 108555 [details] assert repro
Tim Horton
Comment 6 2011-09-23 16:47:24 PDT
But that's a separate problem. As it stands, the first time we get to SVGFEImageElement::build, and go to paint the SVGImageElement, hasImage() is false so it doesn't paint, and from then on we never get anything indicating that we should invalidate.
Tim Horton
Comment 7 2011-09-23 16:48:09 PDT
It almost seems like the notifyFinished calls make it everywhere *backwards*. More debugging!
Tim Horton
Comment 8 2011-09-23 17:11:02 PDT
The more I look at this, the more lost I get. It looks like there are two RenderSVGImages for some reason (I've deleted everything not involved in #twolevel in the original repro), and the second one is not getting a valid image (but really, I'm not sure why it exists at all).
Nikolas Zimmermann
Comment 9 2011-09-24 01:03:50 PDT
(In reply to comment #8) > The more I look at this, the more lost I get. It looks like there are two RenderSVGImages for some reason (I've deleted everything not involved in #twolevel in the original repro), and the second one is not getting a valid image (but really, I'm not sure why it exists at all). Can you attach the smaller repro?
Tim Horton
Comment 10 2011-09-26 17:24:06 PDT
Created attachment 108760 [details] smaller repro surely!
Tim Horton
Comment 11 2011-12-05 12:33:49 PST
This works as of http://trac.webkit.org/changeset/101542, as long as you set the <image> dimensions correctly (width="320" height="320" instead of width="1" height="1").
Note You need to log in before you can comment on or make changes to this bug.