1683440 - mix-blend-mode forces an intermediate texture even when it has no effect

Status: RESOLVED WONTFIX

(Core :: Graphics: WebRender, defect)

Description

[Brad Werth [:bradwerth]]

WR attempts to determine when mix-blend-mode has no effect and optimize the work away. However, in push_stacking_context we let Gecko request that the blend use an intermediate texture.

Since push_stacking_context comes first, there are at least two possible approaches:

1. Make push_stacking_context do some of the analysis done by WR and avoid specifying the stacking context as isolated.
2. Make WR fixup the earlier assumption about the stacking context when it determines that the mix-blend-mode will have no effect.

Comment 1

[Brad Werth [:bradwerth]]

...and I've confirmed that both call sites noted in comment 1 are hit on the www.pixellot.tv site, which was the in-the-wild sighting for this issue.

Comment 2

[Brad Werth [:bradwerth]]

(In reply to Brad Werth [:bradwerth] from comment #1)

...and I've confirmed that both call sites noted in comment 1 are hit on the www.pixellot.tv site, which was the in-the-wild sighting for this issue.

Yes, but: both call sites are hit, but for pixellot.tv the logic at the first site FlattenedStackingContext.is_redundant concludes that the stacking context is not redundant, which makes this potential optimization not useful for that site.

This may still have some value for cases where mix-blend-mode is applied to the first primitive in a stacking context, where FlattenedStackingContext.is_redundant returns true.

Comment 3

[Brad Werth [:bradwerth]]

Attachment: Bug 1683440 Part 2: Make WR stacking contexts able to be made redundant retroactively.

Comment 4

[Brad Werth [:bradwerth]]

Attachment: skew-blend-scroll.html

Comment 5

[Brad Werth [:bradwerth]]

Attachment: Bug 1683440 Part 1: Create a helper function for flushing the work of a stacking context.

This helper function compartmentalizes the logic to transfer the work done by
one stacking context into another stacking context, or to a tile_cache_builder
if no destination stacking context is provided.

Comment 6

[Brad Werth [:bradwerth]]

Attachment: Bug 1683440 Part 1: Add a flag that allows DisplayList to optimize away stacking contexts.

Comment 7

[Brad Werth [:bradwerth]]

Attachment: Bug 1683440 Part 2: Add functions to overwrite serialized PushStackingContextDisplayItem structs.

Depends on D103726

Comment 8

[Brad Werth [:bradwerth]]

Attachment: Bug 1683440 Part 4: Add method DisplayListBuilder::IsCurrentStackingContextEmpty().

Depends on D103727

Comment 9

[Brad Werth [:bradwerth]]

Attachment: Bug 1683440 Part 5: Mark blend containers as needed when mix-blend-mode has an effect.

Depends on D104079

Comment 10

[Brad Werth [:bradwerth]]

Attachment: Bug 1683440 Part 3: Don't create WR commands for fully transparent backgrounds.

Depends on D103727

Comment 11

[Brad Werth [:bradwerth]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=6be45e943caa9f3cdcfcc26fd9ad8f68a461e3cc

Comment 12

[Brad Werth [:bradwerth]]

The testcase used here relies upon aberrant behavior noted in Bug 1599321. The optimization may still be useful, but once that Bug is fixed, the optimization will not be relevant for the testcase attachment 9197517 [details], which relies upon the body element having no specified color.

Comment 13

[Jeff Muizelaar [:jrmuizel]]

I haven't looked closely at this yet but I'm worried about the complexity that it brings. I'll take a closer look soon.

Comment 14

[Brad Werth [:bradwerth]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=5ac1f279ee2505afbd14d5870ee68d256a395069

Comment 15

[Brad Werth [:bradwerth]]

New try push with updated Part 4 (which moved its implementation from Gecko into WebRender): https://treeherder.mozilla.org/#/jobs?repo=try&revision=bb5c109a8dc400cc4f794aab9cb1ecb6eefc1015

Comment 16

[Jeff Muizelaar [:jrmuizel]]

How practical would it be to detect the lack of anything to blend with during Gecko display list building instead of during WebRender display list building? It seems easy for background-blend-mode, I'm not as sure about mix-blend-mode.

Comment 17

[Brad Werth [:bradwerth]]

This optimization is complicated, and the cases where it matters are avoidable by removing the mix-blend-mode which has no effect. The first sighting of this bug was on pixellot.tv, and with other improvements to mix-blend-mode performance, that site now scrolls in software WR without too much jank.

The solution here would be more elegant if we had an intermediate representation that could alter the structure of the display list when processing in parent-child order, but without committing the parent before evaluating the child.

For now, I'll mark this bug as WONTFIX.