Status of the new SVG engine in WebKit

This is really incredible work. If you’ve ever tried some of the more esoteric SVG features like filters and animations, you’re bound to have a horror story or three to share. In almost every case, Safari’s SVG performance lags behind Chromium’s offerings.

Last year I was designing an animated cloudy sky with a sunset. I created a reusable pattern for each cloud type, and added groups for different speeds of movement to give the scene a parallax effect as they scrolled from one end to the other. This proved to be borderline impossible to animate smoothly when more than a dozen cloud paths were in motion. The only fix was to instead move the path translation code to CSS. An instant jump in performance.

The next issue was simulating how sunlight would move across the surface of the cloud patterns. Every single attempt to use an SVG filter or light source would have devastating effects on the frame rate. In my experience, the most powerful primitives of SVGs are not suitable for any task that combines their powers, and as far as I can tell, SVG lighting currently has no use beyond a proof of concept.

I ended up using CSS to get something close to a smooth frame rate. Ironically, reaching for something like Three.js might've saved me a lot of headaches. It’s funny to think that a 3rd party runtime library for WebGL would have a better performance than a universally understood DSL for vector graphics.

I’m sure the web is full of low hanging fruit like this. The hard part is figuring out how we can reaching through the thorns of backwards compatibility.

Kinda fascinating that the changes were too large to merge: "resulting in a monolithic patch exceeding 650 kb of code changes. WebKit demands small patches, with ChangeLogs, tests, etc. – no WebKit reviewer would sign off a patch replacing a core component of WebCore in one shot. Splitting up into small pieces is also not going to work, since SVG needs to be kept intact upstream all the time."