(no title)
hicksyfern | 2 years ago
The thing is, for a lot of it I can’t go into huge amounts of detail otherwise I could write a book on it.
You’re right that the interaction system could keep the SVG as a renderer, and I don’t remember whether that point ended up in the final version! But I have done that locally just for fun to see if it works and it does.
I can give you one example of something that’s too much to go into in a high-level article: SVG and canvas are both very slow at drawing dashed lines. With mapping software, the overall zoom level gets to something like 50 million percent or something ludicrous, and what that means is often you have literal kilometres of dashed lines drawn off screen just if one pixel is on screen for that geometry.
With SVG the only real way to get good perf is to use transforms to move things around when you’re not zooming, or scale them when you are. This doesn’t work if you then need to viewport-clip your lines – you need to render every frame and that gets really slow. With canvas it’s just not a problem, I guess partly because you’re not always making enormous path strings on every frame.
Another example is viewport culling. To avoid thrashing the DOM as you zoom, you don’t really want to be adding and removing elements because it gets janky. We had a viewport culling solution in SVG land with a big dynamic CSS style switching each element on and off which alleviated the browser’s painting workload but it feels hacky as hell. With canvas, you just intersect the viewport with the world and that’s your display list so you render each element in that list. Much simpler model.
Seriously there’s so much involved in making this stuff work well I could literally write a book, but I had to settle for a 2 part article where I had to pick the simplest examples and shortcut some of the detailed explanations.
After all, it’s just a dev blog not an academic paper.
robocat|2 years ago
It is difficult to write a good blog post, and the extra detail is interesting.