Bug 10403 – SVG example exposes problems with <feImage>

• Status: NEW
• Component: SVG

[Eric Seidel (no email)]

Failed to find resource with id: f
Failed to find resource with id: f
Failed to find resource with id: f
Failed to find resource with id: f
Failed to find resource with id: f
(event handler):Null value
Failed to find resource with id: f

[Eric Seidel (no email)]

Hum... that log has been removed since.  This SVG doesnt' work quite right yet.  still have the null value to debug.

[Eric Seidel (no email)]

This no longer has trouble finding resources.  However there are a few errors printed to the console:

(event handler):Null value
(event handler):Can't find variable: im
(event handler):Can't find variable: svgdoc
(event handler):Can't find variable: svgdoc

[Eric Seidel (no email)]

I think this might come from <embed name="sv"> not making the embed available via document.getElementById("sv").  But I'm not sure.

[Eric Seidel (no email)]

Someone just needs to reduce this.

[Nikolas Zimmermann]

Even after all these years, it still has bugs, this time it leads to JSC crashes. Needs further investigation.

Backtrace:

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000bbadbeef
Crashed Thread:  0

Thread 0 Crashed:
0   com.apple.JavaScriptCore      	0x006dd60a JSC::Interpreter::execute(JSC::FunctionExecutable*, JSC::ExecState*, JSC::JSFunction*, JSC::JSObject*, JSC::ArgList const&, JSC::ScopeChainNode*, JSC::JSValue*) + 88 (Interpreter.cpp:678)
1   com.apple.JavaScriptCore      	0x00642a2f JSC::JSFunction::call(JSC::ExecState*, JSC::JSValue, JSC::ArgList const&) + 223 (JSFunction.cpp:121)
2   com.apple.JavaScriptCore      	0x00642b0b JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 211 (CallData.cpp:39)
3   com.apple.WebCore             	0x04084b48 WebCore::JSEventListener::handleEvent(WebCore::ScriptExecutionContext*, WebCore::Event*) + 1020
4   com.apple.WebCore             	0x03e45439 WebCore::EventTarget::fireEventListeners(WebCore::Event*) + 631
5   com.apple.WebCore             	0x03e059d1 WebCore::DOMWindow::dispatchEvent(WTF::PassRefPtr<WebCore::Event>, WTF::PassRefPtr<WebCore::EventTarget>) + 215
6   com.apple.WebCore             	0x03e0654d WebCore::DOMWindow::dispatchLoadEvent() + 101
7   com.apple.WebCore             	0x03d2d29b WebCore::Document::dispatchWindowLoadEvent() + 113
8   com.apple.WebCore             	0x03d382fb WebCore::Document::implicitClose() + 957
9   com.apple.WebCore             	0x03e8bc0c WebCore::FrameLoader::checkCallImplicitClose() + 122
10  com.apple.WebCore             	0x03e8ebab WebCore::FrameLoader::checkCompleted() + 199
11  com.apple.WebCore             	0x03e8ed18 WebCore::FrameLoader::completed() + 156
12  com.apple.WebCore             	0x03e8ebc1 WebCore::FrameLoader::checkCompleted() + 221
13  com.apple.WebCore             	0x03e900bd WebCore::FrameLoader::loadDone() + 17
14  com.apple.WebCore             	0x03d218b6 WebCore::DocLoader::setLoadInProgress(bool) + 116
15  com.apple.WebCore             	0x04225ded WebCore::Loader::Host::didFinishLoading(WebCore::SubresourceLoader*) + 545
16  com.apple.WebCore             	0x04451260 WebCore::SubresourceLoader::didFinishLoading() + 176
17  com.apple.WebCore             	0x043d4b82 WebCore::ResourceLoader::didFinishLoading(WebCore::ResourceHandle*) + 24
18  com.apple.WebCore             	0x043d13b7 -[WebCoreResourceHandleAsDelegate connectionDidFinishLoading:] + 215
19  com.apple.Foundation          	0x90d96497 -[NSURLConnection(NSURLConnectionReallyInternal) sendDidFinishLoading] + 87
20  com.apple.Foundation          	0x90d96403 _NSURLConnectionDidFinishLoading + 147
21  com.apple.CFNetwork           	0x971e1ba4 URLConnectionClient::_clientDidFinishLoading(URLConnectionClient::ClientConnectionEventQueue*) + 212
22  com.apple.CFNetwork           	0x971e28fa URLConnectionClient::ClientConnectionEventQueue::processAllEventsAndConsumePayload(XConnectionEventInfo<XClientEvent, XClientEventParams>*, long) + 310
23  com.apple.CFNetwork           	0x971e1370 URLConnectionClient::processEvents() + 104
24  com.apple.CFNetwork           	0x9718ed03 MultiplexerSource::perform() + 189
25  com.apple.CoreFoundation      	0x932883c5 CFRunLoopRunSpecific + 3141
26  com.apple.CoreFoundation      	0x93288aa8 CFRunLoopRunInMode + 88
27  com.apple.HIToolbox           	0x967e52ac RunCurrentEventLoopInMode + 283
28  com.apple.HIToolbox           	0x967e50c5 ReceiveNextEventCommon + 374
29  com.apple.HIToolbox           	0x967e4f39 BlockUntilNextEventMatchingListInMode + 106
30  com.apple.AppKit              	0x947316d5 _DPSNextEvent + 657
31  com.apple.AppKit              	0x94730f88 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
32  com.apple.Safari              	0x0000c303 0x1000 + 45827
33  com.apple.AppKit              	0x94729f9f -[NSApplication run] + 795
34  com.apple.AppKit              	0x946f71d8 NSApplicationMain + 574

[Nikolas Zimmermann]

I don't see JSC crashes anymore in trunk, but still doesn't work. Maybe a filter hacker can have a look?

[Nikolas Zimmermann]

CC'ing Reni, who might have a clue?

[Nikolas Zimmermann]

Created attachment 111583 [details]
Test image for testcase

I looked into the ripple.svg document contained in Davids waves testcase, we have a problem with the feDispMap filter, which is causing trouble. I've reduced it to a simpler testcase. You'll need foo.jpg as input.

[Nikolas Zimmermann]

Created attachment 111584 [details]
Reduced testcase showing filter problem

[Nikolas Zimmermann]

Created attachment 111590 [details]
ImageBuffer jpg dump of SVGFEImageElement m_targetImage

Fun! I've dumped the ImageBuffer at rx="160" ry="160" that SVGFEImageElement::build() produces.
Obviously the way renderSubtreeToImageBuffer is used here is flawed, more to come.

[Nikolas Zimmermann]

Created attachment 111600 [details]
Another simpler reduction w/o feDispMap

[Radar WebKit Bug Importer]

<rdar://problem/10588362>

[Nikolas Zimmermann]

I fixed the filter problem locally, though there's still a dynamic invalidation problem, which is tricky:
The embedded document looks like this:
<defs>
<filter id="d" >
	<feImage xlink:href="#r" result="grad" />
	<feDisplacementMap scale="20" id="feDM"
	 xChannelSelector="R" 
	in="SourceGraphic" in2="grad"/>
</filter> </defs>
<ellipse id="r" cx="50%" cy="50%" rx="80%" ry="80%"
style="fill:url(#f)"/>
<image filter='url(#d)' id="M" xlink:href='Manjbah4.jpg'  width="100%" 
height="100%" preserveAspectRatio="none"/>
</svg>

The host documents, add an <radialGradient id="f"><stop offset="..."> to the embedded document, and then changes the stop offsets using a <script>.

That _only_ invalidates the <ellipse> as it uses the fill="url(#f). There's no link between the <ellipse> and the <feImage/> so this filter is never going to be invalidated.

We don't support invalidation of any indirect references like this.
If the <ellipse> would be a child of the <feImage> everything would work...

[Tim Horton]

(In reply to comment #13)
> I fixed the filter problem locally, though there's still a dynamic invalidation problem, which is tricky:
> The embedded document looks like this:
> <defs>
> <filter id="d" >
>     <feImage xlink:href="#r" result="grad" />
>     <feDisplacementMap scale="20" id="feDM"
>      xChannelSelector="R" 
>     in="SourceGraphic" in2="grad"/>
> </filter> </defs>
> <ellipse id="r" cx="50%" cy="50%" rx="80%" ry="80%"
> style="fill:url(#f)"/>
> <image filter='url(#d)' id="M" xlink:href='Manjbah4.jpg'  width="100%" 
> height="100%" preserveAspectRatio="none"/>
> </svg>
> 
> The host documents, add an <radialGradient id="f"><stop offset="..."> to the embedded document, and then changes the stop offsets using a <script>.
> 
> That _only_ invalidates the <ellipse> as it uses the fill="url(#f). There's no link between the <ellipse> and the <feImage/> so this filter is never going to be invalidated.
> 
> We don't support invalidation of any indirect references like this.
> If the <ellipse> would be a child of the <feImage> everything would work...

Technically <use> supports invalidation when a target referenced element changes, no? I wonder if we could adapt some of that mechanism?

[Nikolas Zimmermann]

(In reply to comment #14)
> Technically <use> supports invalidation when a target referenced element changes, no? I wonder if we could adapt some of that mechanism?
Well it clones the target into its shadow tree, so this is not really comparable.
Consider:
<filter id="foo">
<feImage xlink:href="#somerect"/>
</filter>
<rect id="someRect" fill="url(#gradient")/>
<linearGradient id="gradient"><stop/></linearGradient>
<image filter="url(#foo)"/>

Say I change the linearGradient stop offset using JS. That would invalidate the <linearGradient>, and cause a repaint of the "someRect". And that's where it stops. There's no connectionb etween "someRect" and the <feImage> that references it.

Note: I have already fixed this locally, by introducing a new HashMap<SVGElement*, OwnPtr<HashSet<SVGElement*>> > in SVGDocumentExtensions. SVGFEImageElement registers the hrefElement with itself there. I'll write up more details tomorrow, about to sleep :-)

[Nikolas Zimmermann]

While I got the test case working locally, I still have to reload a few times before it eventually works, because of bug 15505 - onload sometimes fires too early.
The onload handler of the host document tries to access "document.sv", and the document contains <embed name="sv" src="some.svg">. The unload handler is often fired before the some.svg document is loaded, leading to wrong results.
When chaining onload="prepare()" to onload="setTimeout(prepare, 0)" it seems to work always, but this is only a hack - the document onload event should be delayed until the embed is loaded.

Once bugs 76559 and 76800 landed, I'll post the patch which fixes this test case, except for the onload problem.

[Dirk Schulze]

(In reply to comment #16)

> Once bugs 76559 and 76800 landed, I'll post the patch which fixes this test case, except for the onload problem.

76559 and 76800 landed, where is the patch? :)

[Nikolas Zimmermann]

(In reply to comment #17)
> (In reply to comment #16)
> 
> > Once bugs 76559 and 76800 landed, I'll post the patch which fixes this test case, except for the onload problem.
> 
> 76559 and 76800 landed, where is the patch? :)

Will post it as soon as the SVGLoad & repainting issues are resolved.

[Nikolas Zimmermann]

(In reply to comment #18)
> (In reply to comment #17)
> > (In reply to comment #16)
> > 
> > > Once bugs 76559 and 76800 landed, I'll post the patch which fixes this test case, except for the onload problem.
> > 
> > 76559 and 76800 landed, where is the patch? :)
Waiting at bug 73860.

[Nikolas Zimmermann]

Davids example now works in webkit trunk >r107067. Sometimes it takes one or two reloads until it starts animating, due to bug 15505 -- the SVG bugs are all resolved.