nzimmermann86

It's not the hardware per se. CoreGraphics on macOS/iOS utilizes the GPU for painting, which is much faster than software rendering. Cairo, used for the Linux GTK/WPE ports, is software based, and thus much slower, when painting large scenes.

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).

Agreed - Igalia encourages companies to work upstream, it's part of the idea that we stand for.

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 :-)

Now I'm curios who you are :-)

It totally depends on the implementors, if no one implements it, it won't come. If nobody does the first implementation, no other vendor will follow - it's as easy as this.

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.

It was in earlier SVG2 drafts, but was dropped due to the lack of implementation, see here: https://www.w3.org/TR/2015/WD-SVG2-20150915/render.html#ZInd...