Introducing the layer based SVG engine

In 2005, when the SVG support from ksvg2 was integrated into WebKit, the state of the WebKit rendering engine was dramatically different. There was no support for transformations, only basic rectangular clipping, no masking, no filters, etc. since these features simply did not exist yet for HTML/CSS. All length information related to the CSS box model, such as position/size of a box, were represented as integers - which was obviously not enough for SVG.

The whole layout / painting / hit-testing code had to be adjusted to support affine transformations, advanced painting features, such as gradients, patterns, filters, masks. To minimize the impact for HTML/CSS - which did not need any of that in 2005! - this was developed only for the SVG renderers (we’ll define that term later), not for the HTML/CSS renderers.

When SVG became widespread in browsers, Web developers soon started to demand support for the shiny new SVG features on HTML elements - most noticeable: transformations (and sub-pixel positioning!). In 2007 WebKit pioneered support for CSS Transforms, see a previous article for details. All the features that previously originated in the early 2000s in SVG were steadily specified for HTML/CSS: CSS Transforms Module Level 1, CSS Masking Module Level 1, Filter Effects Module Level 1. Due to these major efforts we have strong specifications describing the interaction/interplay with HTML/CSS on one side and SVG on the other. Strategies were developed to map SVG presentation attributes to CSS properties, that could also be applied to HTML elements. Many integration issues are solved in 2021, that were not specified at all in the early 2000s, when my personal endeavour with SVG started.

In WebKit many of the SVG features were reimplemented in isolation for HTML/CSS, without unifying with the SVG code paths, not because WebKit developers were lazy, but mostly due to the fact that it was not clear at all how to integrate HTML/CSS and SVG in the beginning, e.g.: can you specify the CSS ‘transform’ property on SVG elements? What happens when both the SVG ‘transform’ attribute and the CSS ‘transform’ property are set? Shall the CSS ‘transform’ property be synchronized with the SVG DOM data-structures such as SVGTransformList, and vice-versa? These were all open issues that (partly) have answers in 2021 - not all issues are solved, but the majority are.

However, the way that WebKit paints SVG content today is largely unchanged compared to 2005. On the other hand, during the last decade a lot of effort went into advanced HTML/CSS-only features such as 3D perspective transformations. And most importantly, many investments regarding animation performance (e.g. hardware-accelerated GPU composition for cheap animated transformations).

Unfortunately SVG does not benefit at all from these developments, creating a lot of frustration for Web developers: incompatibilities between CSS/SVG, and most noticeable: performance problems when animating SVGs.

Before talking about the presented solution, a few WebKit specific concepts will be introduced, in order to make this document easy to follow for interested parties that are not WebKit developers themselves. Note that most concepts are more complex than I present them here: the aim is to omit details to concentrate on the big picture.

Navigation: Previous     Next
comments powered by Disqus