mix-blend-mode isn't applied with CSS Animation
Categories
(Core :: Graphics: WebRender, defect, P3)
Tracking
()
People
(Reporter: m_kato, Unassigned)
References
(Blocks 2 open bugs)
Details
(Whiteboard: [gfx-noted])
Attachments
(1 file)
1.67 KB,
image/svg+xml
|
Details |
When using mix-blend-mode on SVG, it works well. But using it with CSS animation, it doesn't work. Attached SVG works well on Chrome, but it doesn't work on Firefox 56. I test on macOS 10.12 + Nightly 56.
Comment 1•7 years ago
|
||
Moving this to graphics because this seems to be simply a result of creating a stacking context (which CSS Animation requires). You can produce the same effect by setting 'will-change:transform' or 'isolation:isolate' on the element. That said, I'm not sure how this is supposed to work.
Comment 2•7 years ago
|
||
Not that familiar with reading SVG, but the transform and mix-blend appear to be on the same element? Is it possible that we're treating the transform as 'outside' the blend, and Chrome is the opposite?
Comment 3•7 years ago
|
||
I can reproduce it on all platforms. Brian, do you have any thought in this?
Comment 4•7 years ago
|
||
No, I'm not familiar with that spec.
Comment 5•7 years ago
|
||
Hello Markus, do you have any thought about this bug? Or could you forward this to someone who might familiar with this part of code?
Comment 6•7 years ago
|
||
I think Brian is right, and this bug happens because we always treat transforms as stacking contexts, or "effect groups" (i.e. implied intermediate surfaces). But in SVG, 2D transforms should not be stacking contexts - blending should happen across transforms. I don't think there's a way for us to fix this with the current layers architecture. At least not complicated rewrapping of display items or leaf layers, and duplicating transform chains. (In reply to Matt Woodrow (:mattwoodrow) from comment #2) > Not that familiar with reading SVG, but the transform and mix-blend appear > to be on the same element? The transform is on the <use> element, and the mix-blend-mode is on the <ellipse> *inside* the <use>.
Updated•7 years ago
|
Updated•2 years ago
|
Comment 9•2 years ago
|
||
Hi there,
Any update on this one..? Wondering what's the exact process, since the bug has been opened for 6y+..
Comment 10•1 year ago
|
||
Makoto, can you report if this behavior continues to exist in the current release of Firefox (109)?
Comment 11•1 year ago
|
||
(In reply to Bob Hood [:bhood] from comment #10)
Makoto, can you report if this behavior continues to exist in the current release of Firefox (109)?
Yes, it still reproduces.
Comment 12•1 year ago
|
||
Hi There,
Since it has been pretty long time, is there an ETA on this issue..? Or is it more abandoned..?
Comment 13•1 year ago
|
||
Glenn, can you have a look-see here? Along with Makato's confirmation, I too have verified using Edge that the SVG is not blending properly in Firefox 109.
Comment 14•1 year ago
|
||
Nical, any ideas here on what might be going on? Is this something that would typically hit a blob fallback path, or should it be native WR display items? I can probably take a look at it next week if it's native WR display items, if it's blob related perhaps Nical or Timothy could investigate further?
Comment 15•1 year ago
|
||
This is SVG code so it automatically at least goes through WebRenderCommandsBuilder, but the latter can opt into deciding whether some display items get rendered via webrender or as part of a blob. In this particular case, the nsDisplayBlendMode
is in an nsDisplayBlendContainer
I don't know what nsDisplayBlendContainer
does, but I can see that we don't attempt to use WebRender items for it if we are in WebRenderCommandsBuilder.cpp, see: https://searchfox.org/mozilla-central/rev/8e9b4484408154b80d7ede9e1b035819fda48fd2/gfx/layers/wr/WebRenderCommandBuilder.cpp#1248
So I guess a first step would be to allow blend containers to be active (that means taken out of the blob and potentially done using a wr display item). I tried that by adding a case for DisplayItemType::TYPE_BLEND_CONTAINER
in IsItemProbablyActive
, and that leads to stacking contexts in the WR display list with mix-blend mode Darken on them (checked by looking at the serialized scene in a capture), however I doesn't appear to change the look of the test case.
I don't know how mix-blend modes work in webrender (or in general). I suppose there are rules about what it can blend with and maybe the resulting display list doesn't let it blend as far as it should? Or maybe the blend container defines the scope of how far up the tree it can blend? in which case the gecko display list isn't quite right since there is one per animated thing?
Sending the needinfo back your way since you have spent a fair amount of time with mix-blend modes.
Comment 16•1 year ago
|
||
I got confirmationfrom jrmuizel that a blend container defines the scope of what the blend items blend with. That would suggest that the problem is in the gecko displaylist, because this test case currently gives us something of the form:
SVG
transfrom
blend container
blend
shape
transfrom
blend container
blend
shape
transfrom
blend container
blend
shape
And for the blending to happen as expected we would need the blend containers hoisted out into a single one, probably more like:
SVG
blend container
transfrom
blend
shape
transfrom
blend
shape
transfrom
blend
shape
Comment 17•1 year ago
|
||
Perhaps something Timothy might have bandwidth to look at and see if it's a Gecko display list building problem as Nical suggests in the comment above?
Comment 18•1 year ago
|
||
Yes, I planned to discuss it with him at our 1x1 tomorrow.
Comment 19•1 year ago
|
||
Hi There,
Some months have been passed, again, so was just wondering what's the status nowadays on this issue..?
Updated•3 months ago
|
Updated•3 months ago
|
Description
•