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)
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...
Reporter | ||
Comment 1•20 years ago
|
||
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... ;)
Updated•15 years ago
|
Assignee: general → nobody
QA Contact: ian → general
Reporter | ||
Updated•14 years ago
|
Blocks: layoutperfarch
Updated•13 years ago
|
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.
Description
•