Introducing the layer based SVG engine

Re:Introducing the layer based SVG engine by eyelidlessness on Monday November 01, 2021 @01:42PM (#29070148)

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

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.

[ Parent | on HN ]

Re:Introducing the layer based SVG engine by onion2k on Monday November 01, 2021 @02:50PM (#29071151)

I’m curious why you went with portals

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.

[ Parent | on HN ]

Re:Introducing the layer based SVG engine by progers7 on Monday November 01, 2021 @04:22PM (#29072539)

This article is just about acceleration and stacking is not introduced. WebKit's architecture ties together the concepts of stacking and acceleration. A positive effect is that it will be quite easy to support stacking in SVG with this work.

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.

[ Parent | on HN ]