1379524 - mix-blend-mode isn't applied with CSS Animation

Status: NEW

(Core :: Graphics: WebRender, defect, P3)

Description

[Makoto Kato [:m_kato]]

Attachment: test.svg

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

[Brian Birtles (:birtles, Feb 26~ parental leave)]

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

[Matt Woodrow (:mattwoodrow)]

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

[Kevin Chen[:kechen] (UTC + 8)]

I can reproduce it on all platforms.

Brian, do you have any thought in this?

Comment 4

[Brian Birtles (:birtles, Feb 26~ parental leave)]

No, I'm not familiar with that spec.

Comment 5

[Kevin Chen[:kechen] (UTC + 8)]

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

[Markus Stange [:mstange]]

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

Comment 9

[Lorand Zudor]

Hi there,

Any update on this one..? Wondering what's the exact process, since the bug has been opened for 6y+..

Comment 10

[Bob Hood [:bhood]]

Makoto, can you report if this behavior continues to exist in the current release of Firefox (109)?

Comment 11

[Brian Birtles (:birtles, Feb 26~ parental leave)]

(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

[Lorand Zudor]

Hi There,

Since it has been pretty long time, is there an ETA on this issue..? Or is it more abandoned..?

Comment 13

[Bob Hood [:bhood]]

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

[Glenn Watson [:gw]]

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

[Nicolas Silva [:nical]]

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

[Nicolas Silva [:nical]]

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

[Glenn Watson [:gw]]

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

[Bob Hood [:bhood]]

Yes, I planned to discuss it with him at our 1x1 tomorrow.

Comment 19

[Lorand Zudor]

Hi There,

Some months have been passed, again, so was just wondering what's the status nowadays on this issue..?