SVG: clip path on a clip path doesn't seem to work sometimes
Categories
(Core :: SVG, enhancement, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox68 | --- | fixed |
People
(Reporter: jrmuizel, Assigned: heycam)
Details
Attachments
(2 files, 1 obsolete file)
svg-clipping-perf.svg
There should be a bunch of green shapes. Firefox draws nothing.
|
Reporter | |
Comment 1•7 years ago
|
||
Here's a further reduced version.
|
|
Reporter | |
Updated•7 years ago
|
|
||
Comment 2•7 years ago
|
||
Well we pass this which has clips within clips: https://www.w3.org/Graphics/SVG/Test/20110816/svg/masking-path-07-b.svg
|
|
Reporter | |
Updated•7 years ago
|
|
|
||
Comment 3•7 years ago
|
||
Well it's all about which element you use for userSpaceOnUse units.
The first clip does not have clipPathUnits and so it defaults to userSpaceOnUse units. Firefox uses the userspace of the original object, the rect. It seems that Chrome uses the space of the other clipPath. That's in objectBoundingBox units so it uses those for the referenced clipPath too.
The SVG spec says this:
If clipPathUnits="userSpaceOnUse", the contents of the ‘clipPath’ represent values in the current user coordinate system in place at the time when the ‘clipPath’ element is referenced (i.e., the user coordinate system for the element referencing the ‘clipPath’ element via the ‘clip-path’ property).
So either interpretation is arguable as far as I can see.
Seems like w3c should clarify things here.
|
|
||
Comment 4•7 years ago
|
||
The downside of Chrome's interpretation is that you can't get back to the original rect units, you're stuck in objectBoundingBox units all the way further down the chain once you encounter one.
|
||
Comment 5•7 years ago
|
||
The example in reduce.svg isn't a clip-path on a <clipPath>, it's a clip-path on the rect which happens to be inside another clipping path. This rect is the "the element referencing the clipPath" in this context. The user-space for the clipped rect is the coordinate system where it has width and height of 1. So Chrome's rendering is correct, IMO: this is definitely a Firefox bug (although it still wouldn't hurt to add clarification to the spec).
That said:
If it was a case of <clipPath id="clip" clipPathUnits="objectBoundingBox" clip-path="url(#clip2)">...</clipPath>, that's when things would get trickier. The spec doesn't clearly define what is the coordinate system for the clipPath itself. In this case, however, both Firefox and Chrome pass through the original user-space coordinates to the final clip. But Edge doesn't, instead treating it the same as a clip on the scaled contents of the clipping path.
Test case: https://codepen.io/AmeliaBR/pen/fd314d690be3c48a72b238d695db395e
So that one definitely needs a spec clarification, and there is an open bug for it:
https://github.com/w3c/fxtf-drafts/issues/247
|
|
||
Updated•7 years ago
|
|
Assignee | |
Comment 6•7 years ago
|
||
For attachment 9047962 [details], here is where we set up the clip that applies to the <rect> inside #clip:
Note that we're passing in aClippedFrame here, which is the actual displayed <rect>. Inside ApplyClipPath, we set up some transforms based on the <circle> and the <clipPath> it's in, but we never do anything with <clipPath id="#clip">'s transform (to take its objectBoundingBox value into account). It's in mMatrixForChildren but we don't use that until we actually paint #clip's children.
I think we should be using mMatrixForChildren instead of aMatrix in that ApplyClipPath call. (And similarly in the clip mask layer case.)
|
|
Assignee | |
Comment 7•7 years ago
|
||
|
||
Comment 9•7 years ago
|
||
| bugherder | ||
Description
•