SVG painting in WebKit is much simpler, as the Layer Tree is not used for SVG at all. SVG 1.1 had no means to change the painting-order – it’s identical to the document order. Therefore the layered painting approach was neglected for SVG in the early ksvg2 days. Remember at this point in time HTML/CSS did not even support transformations, filters, etc.

In a standalone SVG document there is only a single layer for the whole document. The renderer for the outermost <svg> element, that establishes the SVG document, is called RenderSVGRoot and upon painting it will render the whole SVG document by recursively painting all of its descendants in the Render Tree, not utilizing the Layer Tree at all.

In this approach the SVG renderers themselves need to know about transformations, masking, clipping, etc., as opposed to the HTML/CSS renderers. This approach is not bad at all, it will lead to a good static rendering performance, as the whole cost of creating/maintaining the Layer Tree can be avoided, but it’s a nightmare when it comes to animation performance. HTML/CSS and SVG feel different for the Web developers: features that work in HTML/CSS don’t work in SVG, or vise-versa. This perception is true, since the underlying code paths are different: there is no feature parity, just best efforts to keep them in sync.

Furthermore the hardware-accelerated composition developed for HTML/CSS, is not accessible for SVG. Of course, one could implement this from scratch for SVG, but the maintenance cost is so large that this is not a feasible approach. The most appealing approach is to unify the painting approaches, ensuring that RenderLayer can be used for SVG. If SVG would participate in the Layer Tree many long-standing Web compatibility bugs can finally be resolved, such as positioned objects inside <foreignObject>, which is broken in WebKit.

The so-called “Layer based SVG engine” does just that: it unifies the HTML/CSS and SVG rendering approaches. The following sections illustrate the challenges that came up when developing this feature and how they were solved, one-by-one – unfortunately with many twists and windings.