Bug 221788 – clip-path does not update dynamically when svg path changes if using GPU rendering

• Component: SVG
• Status: NEW

[Jonathan Deutsch]

Created attachment 420072 [details]
Reproduction document

If a CSS clip-path is set to an element that uses a SVG id, changing the "d" component does not update the clip path immediately when the element uses GPU acceleration (via transform:rotateY(0deg).

If you resize the window or do something to force redrawing, it will show up correctly.  Not using GPU rendering also will make this work.  It is not a problem on Chrome/Firefox.

I've attached a reproduction case. Click the shape to get the clip path to change. After clicking, do something like resize the window and you'll see it change then.

This affects content made with Tumult Hype [https://tumult.com/hype/].

[Said Abou-Hallawa]

Created attachment 420082 [details]
reduced test case

I think the problem is not related to GPU acceleration or the compositing. I am attaching a reduced test case which does not include any compositing.

I think the problem is when the CSS of an element references an SVG "clip-path", the renderer of this element is not registered as client of the RenderSVGResourceContainer of SVG "clip-path". This is already done for any SVG element which references the same SVG "clip-path" but it is not done for any other non SVG element.

When the SVG "clip-path" changes, its renderer 'RenderSVGResourceContainer' invalidates all the clients in RenderSVGResourceContainer::markAllClientsForInvalidation().

[Jonathan Deutsch]

Yes - it looks like you are correct.  Removal of the rotateY(0deg) from my example leads to different behavior that lead me to think it was the culprit, but with some additional testing I can see there are ways it still is wrong with that. Your example easily repros it.

[Radar WebKit Bug Importer]

<rdar://problem/74501548>