934411 - Use a single nsDisplayItem to paint groups of SVG elements where we'd gain performance wins

Status: NEW

(Core :: SVG, defect, P3)

Description

[Jonathan Watt [:jwatt]]

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

[Jonathan Watt [:jwatt]]

(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.)