1700366 - Models on Sketchfab.com run slower with Webrender software fallback

Status: RESOLVED FIXED

(Core :: Graphics: WebRender, defect)

Description

[Rares Doghi, Desktop QA]

[Affected platforms]:
Platforms: Windows 8 / 8.1 , Windows 7, Windows 10
GPU's : AMD Rx550, Intel HD 5500, Nvidia GeForce 730

[Steps to reproduce]

1. Launch the Firefox browser and set both gfx.webrender.enabled, gfx.webrender.software = true
2. Reach https://sketchfab.com/3d-models/the-turtle-ee2c18fce41c4942b2a99a8638f48858 and wait for the model to load.
3. Move/Rotate the Model, Zoom in/out.

[Expected result]
The 3D modal should rotate and move smooth without any issues.

[Actual result]
The 3D model animation looks like its losing frames, its slow when its being rotated or zoomed in and out.
Please note that with WebRender enabled but with gfx.webrender.enabled, gfx.webrender.software = FALSE, this issue does not occur.

Comment 1

[Rares Doghi, Desktop QA]

Attachment: about_supps.txt

Attaching the about:support file

Comment 2

[Rares Doghi, Desktop QA]

Attachment: Firefox 2021-03-23 14.57 profile.json.gz

Comment 3

[Rares Doghi, Desktop QA]

Attachment: Firefox 2021-03-23 14.42 profile.json.gz

Adding 2 Performance profiles captured in Beta and Nightly

Comment 4

[Jeff Muizelaar [:jrmuizel]]

I can reproduce this locally. It looks like we're spending a bunch of time in the drawing gradients (presumably every time the webgl updates)

Comment 5

[Jeff Muizelaar [:jrmuizel]]

The webgl canvas's parent element has a background-image: linear-gradient(), linear-gradient(). Disabling this background-image improves performance dramatically.

Comment 6

[Jeff Muizelaar [:jrmuizel]]

The webgl appears to have {alpha: false} so we should be able to avoid doing this drawing. Glenn, do we have the infrastructure to prevent this drawing from happening? Shouldn't the depth buffer be saving us at a minimum?

Comment 7

[Glenn Watson [:gw]]

It's failing to promote the webgl canvas to an external compositor surface because it thinks that the canvas needs a clip-mask applied.

This means that the canvas is composited into the picture cache slice, and thus invalidates the tile, causing rasterization of both the gradient and blitting the canvas into the tile every time it's rotated.

It's not clear to me yet why it thinks it needs a clip-mask - investigating further now.

Comment 8

[Glenn Watson [:gw]]

The clip that results in a mask is a normal rectangle clip, there are no complex clips involved.

WR creates a mask as it thinks that the clip rectangle is in a different coordinate space (non-axis-aligned) than the primitive - it's not clear yet whether that is a simple bug, some accuracy issue, or a genuine issue.

Comment 9

[Glenn Watson [:gw]]

The source transform for the canvas surface is source_transform: Value([1.0008518, 0.0, 0.0, 0.0, -0.0, -1.0, -0.0, -0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 657.0, 0.0, 1.0]) which looks like it should be handled as a ScaleOffset. Perhaps the -0.0 is tripping up the logic that determines if a transform only contains scale / offset.

Comment 10

[Glenn Watson [:gw]]

It's actually the negative scale / reflect that is causing WR to select this as a different coordinate system. However, if I allow that to be considered a ScaleOffset the webgl surface doesn't draw at all, so there is a deeper reason why we don't currently handle this as a compatible coordinate system.

Comment 11

[Glenn Watson [:gw]]

This will be fixed when #1700539 lands.

Comment 12

[Glenn Watson [:gw]]

This should be fixed in m-c now - if you enable the picture caching debug overlay, you should be able to rotate the model without any tile invalidations occurring. If you're able to verify this, we can close this bug.

Comment 13

[Rares Doghi, Desktop QA]

Yup this issue is verified as fixed in 89.0a1 (2021-03-31).

Comment 14

[Glenn Watson [:gw]]

Great, thanks for checking.