Bug 68664

Summary: <feImage> referencing an <image> via xlink:href doesn't display correctly
Product: WebKit Reporter: Tim Horton <thorton>
Component: SVGAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: krit, webkit-bug-importer, zimmermann
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
repro
none
assert repro
none
smaller repro none

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
Details
assert repro (480 bytes, image/svg+xml)
2011-09-23 16:34 PDT, Tim Horton 		no flags
Details
smaller repro (218.71 KB, application/zip)
2011-09-26 17:24 PDT, Tim Horton 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1 2011-09-22 17:05:21 PDT
<rdar://problem/10172530>
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.