1739295 - layerization on google slides is bad

Status: ASSIGNED

(Core :: Graphics: WebRender, defect)

Description

[Jeff Muizelaar [:jrmuizel]]

e.g. https://docs.google.com/presentation/d/10CTMoztn2LiX-Og5TDSuXUsEDrqwTAZFssDDsAprsQg/edit?skip_itp2_check=true#slide=id.ge0ba69ed88_21_0

We're getting a bunch of layerization because of will-change: opacity;. This causes all of the parent opacity/transforms to become active as well.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

Attachment: Just the SVG

Comment 2

[Jeff Muizelaar [:jrmuizel]]

Chrome also layerizes but I haven't been able to figure out if it does a better job

Comment 3

[Jeff Muizelaar [:jrmuizel]]

We're getting an overdraw of about 2.5x here. It looks like non-WebRender would probably get something similar.

Comment 4

[Jeff Muizelaar [:jrmuizel]]

Attachment: A reduced test case showing extra layerization

This reduced test case shows a problem that we have that causes extra layerization. The rough structure o the page is:

<svg>
 <rect area=lots id=A>
 <g transform>
    <rect area=lots id=B>
    <g style="will-change: opacity">
      <text>Mobile</text>
    </g>
 </g>
</svg>

The will-change: opacity forces the <g transform> to be active which prevents rect A and rect B from being merged into the same layer.

I looked a bit into what Chrome does for layerization but there seem to be bugs so I'd like those fixed or understood first.

Comment 5

[Nicolas Silva [:nical]]

Attachment: Bug 1739295 - Simplify parameter passing a bit in blob grouping code. r=jrmuizel

The goal of the GroupingState struct is to allow a followup patch to recursively group while keeping track of the item range, so that we can make better grouping decisions.
In addition there's an armada of builders and helpers passed everywhere through the various functions involved. Putting them in the Builders struct simplifies that a bit.

Comment 6

[Nicolas Silva [:nical]]

Attachment: WIP: Bug 1739295 - WIP - Attempt to make blob grouping more flexible.

This attempts to make the grouping logic recursive so that we can make an item active without making it's parent active.

Part of the challenge is that determining the proper item range isn't enough for the painting code to do the same traversal.

Comment 7

[Nicolas Silva [:nical]]

Attachment: An even simpler version of the test case

Comment 8

[Jeff Muizelaar [:jrmuizel]]

Attachment: simpler than even simpler

More readable than before

Comment 9

[Nicolas Silva [:nical]]

Attachment: barely any less simple with post-split items

Comment 10

[Nicolas Silva [:nical]]

Attachment: What we would like the layerization to be like for a test case equivalent to the "Just the SVG one".

Comment 11

[Nicolas Silva [:nical]]

Attachment: Bug 1739295 - Adjust reftest expectations. r=#gfx-reviewers

Comment 12

[Phabricator Automation]

Comment on attachment 9269057 [details]
Bug 1739295 - Adjust reftest expectations. r=#gfx-reviewers

Revision D141846 was moved to bug 1686654. Setting attachment 9269057 [details] to obsolete.