Last Comment Bug 934411 - Use a single nsDisplayItem to paint groups of SVG elements where we'd gain performance wins
: Use a single nsDisplayItem to paint groups of SVG elements where we'd gain pe...
Status: NEW
: perf
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: All All
P3 normal with 3 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Jet Villegas (:jet)
Depends on: 1049256
Blocks: 869505 1013297 1103397
  Show dependency treegraph
Reported: 2013-11-04 03:51 PST by Jonathan Watt [:jwatt]
Modified: 2014-11-23 13:54 PST (History)
13 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Jonathan Watt [:jwatt] 2013-11-04 03:51:04 PST
The work to convert SVG to display lists and leverage their power gave us some big performance wins on many examples of dynamic SVG content. On the down side the overhead of display lists and layers on more static SVG (which not infrequently contain elements numbering in the thousands, tens of thousands, or much more) has in cases been a significant performance loss.

At the recent Rendering Work Week in Paris, Matt and Robert suggested that we should try to group SVG elements under a single nsDisplayItem where possible.

Robert's suggestion of how we could do that goes something like this: make SVG frames start out with an NS_FRAME_CAN_GROUP_IN_DISPLAY_LIST_ITEM bit. If at some point we notice that we need to or want to create a display list item for an SVG frame (e.g. if it is an nsSVGForeignObjectFrame, or if animations mean we think it would be good to create an nsDisplayTransform, nsDisplayOpacity, or nsDisplayClip, or nsDisplayEffects display list item) then clear that bit from the frame all the way up to the nearest nsSVGOuterSVGFrame.

When we build the display lists we would then create a single nsDisplaySVGGroup item for adjacent siblings that still have the NS_FRAME_CAN_GROUP_IN_DISPLAY_LIST_ITEM bit set. That nsDisplaySVGGroup would then be responsible for painting all those siblings. In the case of a completely static SVG we'd then paint the entire SVG with a single display list item and skip overhead of display lists and layers.
Comment 1 User image Jonathan Watt [:jwatt] 2014-06-02 09:40:58 PDT
(Bug 808318 and bug 1018461 are broken on the non-display-list paint path. As is bug 997735, I think. Before we can implement this optimization we'll need to figure out and fix the things that are broken on the non-display-list path, or prevent the optimization for branches in the tree that contain those things.)

Note You need to log in before you can comment on or make changes to this bug.