Small step towards https://bugs.webkit.org/show_bug.cgi?id=90738
Created attachment 190365 [details] Patch
Comment on attachment 190365 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=190365&action=review Looks very promising. r=me with some text enhancement requests. > Source/WebCore/ChangeLog:10 > + chain but does not enble any layer-related SVG features. Please add a description why we do not allow the creation of layers. That we need to verify that SVG transforms still work on elements that create layers. > Source/WebCore/rendering/svg/RenderSVGModelObject.cpp:113 > + // FIXME: SVG layers not allowed yet. Can you add a note that we do not allow it, since we do not know the influence on transforms? I think this is the main problem. When we have tests that verify that transforms work on creating a layer, we are fine. But we would need to have at least one property creating a layer for sure. Not sure where we might even benefit from. opacity?
(In reply to comment #2) > But we would need to have at least one property creating a layer for sure. Not sure where we might even benefit from. opacity? Yes, opacity+fO are prime candidates: https://bugs.webkit.org/show_bug.cgi?id=23113
Can we chat about this over VC or #webkit sometime? I'm not sure this is the right direction for SVG or the rendering tree.
(In reply to comment #4) > Can we chat about this over VC or #webkit sometime? I'm not sure this is the right direction for SVG or the rendering tree. To be honest, this bug report does not give the full strategy. Therefore it might be unclear where it is going. To shorten it, we need RenderLayers in some situations to share different capabilities. These are 3D transforms, maybe filters, maybe masking and maybe opacity. To shorten it, everything that can use HW accelerated rendering or where it makes a lot of sense to share the code path with HTML. We should avoid creating layers as much as possible IMO. Transforms are heavily used in SVG. I fear that it is a general overhead to create a RenderLayer for each element. I am happy to chat about this and I want to have everyone on board.
Sure. You want GraphicsLayers for all the 3d stuff. You'll want something to participate in stacking. But I don't think you want all the bloat and CSS-specific goop that is RenderLayer.
The RenderLayer size is smaller nowadays, all the CSS related overflow/scroll handling is moved out to RenderLayerScrollableArea, that a RenderLayer can own, similar to RenderLayerFilters (both optional). There is still potential for optimizations. Anyhow this bug report no longer blocks 90738 - I'm therefore changing the relationship between the tickets (swap depends <-> blocks).
This code has been significantly refactored since this patch was proposed. There doesn't seem to be any action we can take here.