1885451 - ExternalSurfaces can't be relied on to reach e.g. DCLayerTree

Status: NEW

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

Description

[Kelsey Gilbert [:jgilbert]]

We have heuristics to try to keep the total number of os-compositor-level surfaces (ExternalSurfaces and our main surface(s)) below a limit to ensure we get hardware layer composition. However, there are cases (like color management) that require ExternalSurfaces "punch through" webrender where possible (e.g. no css filters, etc) such that we can do color management at the os-compositor stage. (e.g. with DCLayerTree)

We need a way to ask for surfaces to ignore the promotion/demotion due to "too many ExternalSurfaces", and just accept that we don't get maximally efficient window manager compositing in this case.

Comment 1

[Brad Werth [:bradwerth]]

Now that Bug 1898621 has landed, we have logging that will help us understand the reasons why surfaces are being rejected for promotion. Thus far, the logging has revealed that most of the time, the rejection is not because of hitting a limit of too many promoted surfaces. That said, we still may want to force promotion for color managed surfaces even if WebRender thinks it will produce a defective frame, because wrong colors are a highly-visible kind of frame defect that is probably worse.

I'll try to build a patch that detects color managed YuvImage prims and forces promotion as much as possible.

Comment 2

[Brad Werth [:bradwerth]]

Attachment: Bug 1885451: Let WebRender ignore some types of surface promotion failures for wide color videos, and report them.

This also changes the callsites of the error handling function a bit, to
remove the promotion_result_reported output, which is not very useful.
The promotion_result is defined within the prim-specific blocks, and
reported when we check for an error at the end of the block.