Bug 19432

Created attachment 21568 [details] SVG animation with redraw issues

With a debug build, I get an assertion failure when I open the attachment. Thread 0 Crashed: 0 com.apple.WebCore 0x02c2ec68 WTF::HashTableConstIterator<WebCore::SVGSVGElement*, WebCore::SVGSVGElement*, WTF::IdentityExtractor<WebCore::SVGSVGElement*>, WTF::PtrHash<WebCore::SVGSVGElement*>, WTF::HashTraits<WebCore::SVGSVGElement*>, WTF::HashTraits<WebCore::SVGSVGElement*> >::checkValidity() const + 70 (HashTable.h:184) 1 com.apple.WebCore 0x02c2f84c WTF::HashTableConstIterator<WebCore::SVGSVGElement*, WebCore::SVGSVGElement*, WTF::IdentityExtractor<WebCore::SVGSVGElement*>, WTF::PtrHash<WebCore::SVGSVGElement*>, WTF::HashTraits<WebCore::SVGSVGElement*>, WTF::HashTraits<WebCore::SVGSVGElement*> >::operator++() + 24 (HashTable.h:160) 2 com.apple.WebCore 0x02c2f8c3 WTF::HashTableIterator<WebCore::SVGSVGElement*, WebCore::SVGSVGElement*, WTF::IdentityExtractor<WebCore::SVGSVGElement*>, WTF::PtrHash<WebCore::SVGSVGElement*>, WTF::HashTraits<WebCore::SVGSVGElement*>, WTF::HashTraits<WebCore::SVGSVGElement*> >::operator++() + 17 (HashTable.h:235) 3 com.apple.WebCore 0x02c2f8d9 WTF::HashTableIteratorAdapter<WTF::HashTable<WebCore::SVGSVGElement*, WebCore::SVGSVGElement*, WTF::IdentityExtractor<WebCore::SVGSVGElement*>, WTF::PtrHash<WebCore::SVGSVGElement*>, WTF::HashTraits<WebCore::SVGSVGElement*>, WTF::HashTraits<WebCore::SVGSVGElement*> >, WebCore::SVGSVGElement*>::operator++() + 17 (HashTable.h:1101) 4 com.apple.WebCore 0x02c2ca9c WebCore::SVGDocumentExtensions::startAnimations() + 96 (SVGDocumentExtensions.cpp:79) 5 com.apple.WebCore 0x0285072d WebCore::Document::implicitClose() + 1265 (Document.cpp:1606) 6 com.apple.WebCore 0x028e888c WebCore::FrameLoader::checkCallImplicitClose() + 226 (FrameLoader.cpp:1340) 7 com.apple.WebCore 0x028f48a2 WebCore::FrameLoader::checkCompleted() + 268 (FrameLoader.cpp:1295) 8 com.apple.WebCore 0x028f7312 WebCore::FrameLoader::finishedParsing() + 90 (FrameLoader.cpp:1243) 9 com.apple.WebCore 0x0284e864 WebCore::Document::finishedParsing() + 204 (Document.cpp:3725) 10 com.apple.WebCore 0x02d6045e WebCore::XMLTokenizer::end() + 366 (XMLTokenizer.cpp:1392) 11 com.apple.WebCore 0x02d60805 WebCore::XMLTokenizer::finish() + 37 (XMLTokenizer.cpp:1400) 12 com.apple.WebCore 0x028488f2 WebCore::Document::finishParsing() + 40 (Document.cpp:1690)

Assertion filed as bug 21004.

Created attachment 23671 [details] Single cube with <use>

Created attachment 23672 [details] Single cube without <use> These testcases seem to indicate that <use> is the issue here

The problem seems to be related to the fact that with <use>, the render tree is recreated for every frame of animation, and in that case the correct repaints don't happen.

Created attachment 23742 [details] Further reduction of single-cube Strangely enough, lots of pieces of this SVG seem to be required to produce this redraw error. 1. using an object directly, instead of using a <symbol> does not reproduce 2. removing the background color does not reproduce 3. removing the "spline" calc mode does not reproduce 4. changing the <use> to have a viewport exactly fitting the symbol does not reproduce Seems that there are just some errors in viewport coordinate calculations during invalidation which are tripping this up. This needs further reduction and investigation.

Hm, first of all we should track down why simple things like <use xlink:href="someSymbol"> <animate/> </use> crash. I guess it's symbol specific. When <use> on <symbol> is referenced, an internal SVGSVGElement is created (as required by the spec). I guess this SVGSVGElement registers as time container and makes trouble. Antti, can you comment?

(In reply to comment #7) > Created an attachment (id=23742) [edit] > Further reduction of single-cube > > Strangely enough, lots of pieces of this SVG seem to be required to produce > this redraw error. > > 1. using an object directly, instead of using a <symbol> does not reproduce The redraw error, or the assertion? > 2. removing the background color does not reproduce Can't confirm that. > 3. removing the "spline" calc mode does not reproduce Does not happen here, at least not with the original testcase. > 4. changing the <use> to have a viewport exactly fitting the symbol does not > reproduce Can't confirm that as well, with the original testcase. Weird, maybe I'm doing sth. incorrectly...

Independent of the asserts or crashes, the animation performs much more smothly. There is no recognizable differenced between <use> or no <use>-element. I suggest to close this bug and add new bug reports (smfr did it partly already) for every single problem showed here. The bug with the wrong repaint rect seems to be fixed.

Even Nikos bug does already exist: bug 21590. Any objections to close this bug?

No more problems here, redrawing fixed, and covered by new testcases. Related to the assertion that we were seeing sometimes with the old code, the same problem was visible in animate-elem-30-t.svg, where the left animation sometimes took the wrong path - all due to stale shadow / instance trees, that issues is resolved in ToT. Closing bug.