[Webkit-unassigned] [Bug 36564] Performance regression for setting content of <text> in SVG

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=36564





--- Comment #4 from Dirk Schulze <krit at webkit.org>  2010-03-25 14:06:04 PST ---
(In reply to comment #3)
> Hey Dirk!
> 
> (In reply to comment #2)
> > Ok, I analysed the repaintRect issue. The main problem is, that RenderSVGRoot
> > and RenderSVGContainer can't store the repaintRects at the moment. This causes
> > multiple calls of clipperBoundingBoxForRenderer, maskerBoundingBoxForRenderer
> > and other resources.
> 
> Why can't they store repaintRects at the moment?

The renderer don't know, when the repaintRects need to be recalculated. They
don't know if a child or resource changes it's repaintRect. The repaintRect of
a container like g is not only the unite of all child repaintRects, it also get
clipped to the currently visible area. 
This saves a lot of calculations and unnecessary drawings. One test for this
problem is WebCore/manual-test/svg-node-count-vs-scroll.xhtml
You can see the problem on storing the rapaintRect, if you have a big SVG,
where you need to scroll.

Never the less. Even if we could store the values, because the renderer _would_
be able to congnize if they need updates, your test would still be slow the
first time you press "Sets content of the red text 50 times". We still need to
calculate all values at least the first time.
It looks like one problem is getRenderSVGResourceById(). This calls
getElementById() what is rather inefficient. We need getRenderSVGResourceById
to get the correct repaintRect. 
And we can't surrender this calls, since they can make the repaintRect bigger
(eg on using masks or filters).

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.