Closed Bug 270264 Opened 20 years ago Closed 12 years ago

SVG frame construction for DOM-inserted nodes is pretty slow

Categories

(Core :: SVG, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: bzbarsky, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: perf)

The basic setup is that of adding a bunch of SVG nodes via the DOM. Right now, we do the following for each one: 1) Construct a frame (fine) 2) When this frame is inited (_before_ it's inserted into the frame tree, at the point when its style context is set), call UpdateGraphic(). This does two things: calls Update() on the path geometry and then invalidates the resulting dirty region in the viewmanager (and uses NO_SYNC, for that matter, not DEFERRED). The result is that we invalidate the same things over and over and over. I think the right way to do this would be to do all this updating off a PLEvent, with a view update batch about the whole thing. This way the _second_ call to UpdateGraphic() (the one we get when we insert the frame into the frame tree, after all) would get coalesced in too. That should allow us to coalesce DOM changes that the page makes all at once... Thoughts? I'm not sure how many geometry objects we have floating about and hence where would be the best place to post the events...
One other note... I think doing a geometry update just because DidSetStyleContext got called is a little too eager in general, and will cause us to do invalidate things before reflow has happened. I realize that this is not an issue for pure SVG because there's no reflow involved, but in a style change that causes the geomtry frame's style context to change _and_ triggers a reflow that moves the <svg> element, we may get issues because the invalidate will happen immediately, and at the old position, whereas the position may change before the paint. If we really do need to do something to every single path geometry frame that has style "really change" (for some definition of "really change" that someone more familiar with svg would have to provide) we should either make use of existing "repaint" hints or create a new style hint and use it, and have a method on nsIFrame that will be called from ApplyRenderingChangeToTree and that this code can use to call UpdateGraphic(). I hope I'm making a modicum of sense here.. I'm still sorting out how the svg code fits together... ;)
Assignee: general → nobody
QA Contact: ian → general
Depends on: 614732, dlbi
I think this is fixed, but I'm not sure. Please reopen if I'm wrong.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.