Introducing the layer based SVG engine
blogs.igalia.com
blogs.igalia.com
In my previous role I worked on a React app that was essentially just a big SVG editor for lawyers to make legal step diagrams (complex maps of legal structures that define how they change over time). Our solution to the z-index issue was to make extensive use of React portals to things lower down the doc tree when they were in focus. It worked really well, but I would have killed for proper z-index support. It would have greatly simplified my code.
I don't really care about the GPU acceleration; adding layers to SVGs is an amazing change on its own. Kudos to the team behind this. I hope it gets adopted everywhere.
I’m curious why you went with portals? Seems to me you could use the normal render cycle to control order (keyed if you intend to just reorder siblings).
> I don't really care about the GPU acceleration; adding layers to SVGs is an amazing change on its own.
I may be mistaken but in my reading of the article, my understanding is that SVG layers are only about acceleration, and don’t change the stacking semantics of SVG elements. But maybe I missed something.
We had to move things to the front of the SVG no matter where they were in the document. If it was just siblings it'd have been much easier.
Also, these are complex SVGs. On a large diagram there can be 50,000 elements in the SVG. Portals made it simpler.
A negative of joining the concepts of stacking and acceleration is that it is difficult to get acceleration without introducing paint order bugs where the accelerated content starts painting above non-accelerated content.
I understand what they are as a dev but I'm not a lawyer so I can't point you to anything more unfortunately.
For WebKit/SVG, features as z-index are easy to implement in the layer based SVG engine - it's currently disabled, but only because it's lacking dedicated tests: I'd still need to write new reftests covering that.
I'd also Appreciate Igalia sponsoring people like him who are enthusiastic to these open source projects.
[1] https://blogs.igalia.com/nzimmermann/posts/2019-11-24-back-in-town/There are downsides to only having Google/Apple/Mozilla participating in this process, and it's that (regardless of whether you think they have good or bad intentions) they are extremely insular.
There are dangers to this as well of course. We don't want things getting derailed or worsened just because it makes life more convenient for some company somewhere. But in general I suspect it's good for more stakeholders to be getting their hands dirty engaging with both the standards processes and the minutia of actual browser development. They had a problem, they gave money to developers to fix it, and it got fixed with approval from upstream. In terms of Open Source, a pretty clear success story to me. We should encourage this.
A patch like the layer based SVG engine is imposssible to maintain by a single company - e.g. Vorwerk, downstream, for an extended period of time. You want to be able to follow upstream (e.g. for security updates), and that's hard when you change a piece of the core engine with your own stuff.
To suceed, you _need_ to work upstream :-)
It's no different to Valve hiring CodeWeavers to implement new things in the Linux kernel to advance their efforts with Proton. Steam isn't in the kernel development space, but it behooves them to improve the kernel with features that are useful to more than just themselves, since features that are _only_ useful to them are likely to be rejected.
Is there no alternative for what they're using it for? How much extra money does this use bring in? Who managed to convince management to do this and how did they do it?
(I also imagine it's not so much a critical note as it is a "wow, I'd really like to understand the economics of this". It is for me.)
Honestly, this sort of thing is more effective marketing to me than any communication strategy. In brand awareness and "employer-ability".
And yes of course we did consider that this might attract more like-minded fellows who are eager to build great products with great colleagues than our „corporate job advertisement“ ^^
I had the assumption that efficient SVG rendering in Safari was critical and a UX bottleneck to work on from an Apple perspective, but maybe Apple hardware makes it moot.
Therefore for embedded devices using WebKit/Linux GTK/WPE ports we see a huge improvment with the layer based engine. Also macOS/iOS benefits though -- animations are even faster, and you don't easily run into problems, when animating parts of a complex document. It's shown in the video linked in the article at the end: > 20% frame rendering time improvement on an already quite efficient rendering pipeline (Safari / macOS using CoreGraphics on M1 machine).
That's actually how progress gets made - by people doing thankless work in obscurity. Then opportunists usually take that effort, make it fit an existing industry and charge whatever the market will bear.
It'd all be fine if the middlemen didn't then proceed to claim greatness, insight and ingenuity, but they do (because then older middlemen give them money to replicate their success).
This social structure is quite bad because it makes people think the middlemen are capable of creating value through their 'insight', without people who did unsexy, hard, thankless work prior.
Anyhoo :)
Ah, you crystallized something for me. Thanks!
This is why companies like Google and Microsoft are big contributors to Linux: They add features they care about.
As for why companies care about upstreaming: It’s not even because they’re so kind (though FOSS contributions are good marketing) - it just tends to be easier than maintaining a private fork.
The biggest limit is resources. SVG is too big to be implemented by a lone wolf working for love alone, and too diverse in application for a tech company to embrace for the length of time and breadth of focus required.
This is a welcome development that validates the W3C model in a positive, constructive way.
TBL would be pleased I imagine.
So they mostly suck is what I hear you saying
Apple has allegedly spent billions on the development of a car, yet could not spend what was probably $100K of consultancy to fix this issue.
Still, FAANGS have trillions, so why not, you might wonder, splash a drop here or there?
The reason in practice is that to get any significant dev adopted in a FAANG is a competitive process with career advancement at stake.
Only so many projects can level up year after year, because there are limited eyes and ears at each successive level that approve funding.
"I contributed some highly impactful performance improvements for a blender."
"For Blender?"
"No, for a blender."
It’s a great development and the key to open standards success. Not, of course, that a kitchen appliance manufacturer stepped up, but that any outsider was interested and willing to contribute to a general computing tech stack.
For a thousand flowers to bloom, the bird must leave the nest.
This is not a good look for Apple IMO. I completely dropped iOS support for an app I made because it used SVG's and clogged up every iPhone. It's a serious issue.
The world just doesn't work that way. There's a shortage of talent out there, and they often don't want to work for the richest players.
If faster SVG graphics were an impediment to Apple’s business it would likely have been prioritised and fixed by them.
I assume Apple didn't implement this change in-house because they don't need higher-performance SVG rendering.
Alternatives could’ve been switching engines, the animation approach, the UI toolkit or throwing more hardware at it.
At the scale they operate it makes sense, I guess. They likely already have a large code base on their current technology, lots of devices already sold and more powerful hardware might cut into margins by half a percent.
How fast would hardware accelerated SVG be compared to Canvas?
[1] https://wiki.gnome.org/action/show/Projects/LibRsvg?action=s...
Web standards effectively mandate the SVG and HTML implementations be implemented on top of the same DOM, because when you embed an SVG inside an HTML document, you're allowed to use CSS selectors like `html div svg path { stroke: blue }` and JavaScript that treats SVG elements as being part of the HTML document.
librsvg's API isn't nearly rich enough to allow this. It just takes a blob of bytes and turns it into Cairo draw commands. Gecko doesn't even use Cairo any more, it uses Skia. librsvg does have a DOM, but it's intentionally not exposed as part of the API, so that the DOM can be refactored at will without breaking anything.
Looking roughly at the source code [0], it seems it has its own SVG engine.
[0] https://github.com/mozilla/gecko-dev/tree/master/layout/svg https://github.com/mozilla/gecko-dev/tree/master/dom/svg
I wonder if this is something Mozilla will need to address, or if the use cases are small enough that it's not worth the cost.
The documents don't mention if their engine is suitable for "dropping in" to the Cocoa/CocoaTouch/NSwhatever system, but gosh, that would be a heck of a treat…
How can you show video in SVG?
What if you decided to build your entire UI in SVG, and then someone asks to add video? Would you have to rewrite your entire UI using a different approach?
There must be a law that says that the most interesting technology can never win because that would make the universe too nice.
Flash had GPU acceleration 10 years ago.
I can't help thinking a majority of comments like GP never actually used flash or was active on the internet during it's height.
Flash devs from 10 yeasr ago would only be impressed by how many new APIs to talk to the host OS there are.
Flash had a lot like a file API, local storage, and webcam support. But there's definitely a ton more now.
I hope someday someone will crack GPU accelerated vector path rendering.
Wasn't raphlinus doing work on that?
@dang-- is there a bot on here that can shoot out the relevant post/comment/etc.?
I am guessing many commercial users of WebKit can be guessed by looking at the list of Committers (of which Igalia has quite a few): https://webkit.org/team/
(Joke being that the music box which replaced simple moving parts with a bunch of circuitry might even have a version of Electron running somewhere in its guts...)