1686804 - [sw-wr] Windows 10 talos xperf test doesn't appear to composite any frames

Status: RESOLVED INACTIVE

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

Description

[Andrew Osmond [:aosmond] (he/him)]

Investigation into why bug 1684170 got backed out lead me to conclude that we don't properly render frames for the Windows 10 talos xperf test with Software WebRender. Bug 1684170 allowed the test to actually use SW-WR at all -- before it would have been running with Basic because it was denied to lacking D3D11 ANGLE support. This initially appear to be because the test configuration appears to be running with a WARP device ID; however disabling the D3D11 compositor with SW-WR did not resolve the issue.

After bug 1679215 landed, the test began passing with SW-WR, presumably because we create a tiny scratch buffer to allow compositing to continue, allowing the higher level events to fire and the test to move forward:

https://searchfox.org/mozilla-central/rev/2a24205479519e70c0574929f45730d285141584/gfx/webrender_bindings/RenderCompositorSWGL.cpp#146

The reason we failed to get a mapped buffer is because we hit this error path:

https://searchfox.org/mozilla-central/rev/2a24205479519e70c0574929f45730d285141584/widget/windows/InProcessWinCompositorWidget.cpp#134

where the size of the surface is 0x0. Presumably this represents a cairo surface with an error code.

Comment 1

[Andrew Osmond [:aosmond] (he/him)]

Note that we see the same thing on the Windows 7 SW-WR xperf test, however it goes away after a half dozen attempts to create the DrawTarget.

Comment 2

[Andrew Osmond [:aosmond] (he/him)]

It hits this path to create an opaque surface:

https://searchfox.org/mozilla-central/rev/2a24205479519e70c0574929f45730d285141584/widget/windows/InProcessWinCompositorWidget.cpp#126

It does not appear to fail creating the cairo surface as I initially suspected, that succeeds. We have a client size of 1024x772.