1658600 - Performance regression if HWA disabled

Status: NEW

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

Description

[Alice0775 White]

Attachment: about:support

When I test Bug 1658591 on Windows10. I found a performance regression.

Steps To Reproduce:
0. Disable HWA

1. Turn to maximize window
2. Visit http://asciicker.com/y6
3. Observe fps indicator at center of header bar and wait until fps indicator stabilizes.

Actual Results:
on Low spec machine
Firefox78: 25+fps
Firefox79: 18-fps
gecko profiler: https://share.firefox.dev/3gITnOK

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ca8139d58d58ea03def4ff2375ab9010cbd2a1b3&tochange=567a8768593eb06a86deb263f94d9de2d3d3e8fa

Comment 1

[Markus Stange [:mstange]]

Different view into Alice's profile: https://share.firefox.dev/2YuVA9F

We're doing readback in the content process, as expected. However, in addition to the blocking and copying inside glReadPixels (41%), we have the following extra costs per frame:

• Allocation and zero-fill of a shmem (20%)
• Allocation and zero-fill of a DataSourceSurface (14%)
• Conversion from BGRA to RGBA (or maybe the reverse?) (8%)
• Copy from the DataSourceSurface into the shmem (11%)

The allocation and zero-fill costs could be avoided with some kind of pool.
The conversion could maybe avoided by having ANGLE do it, so that it could be combined with the copy that happens in rx::PackPixels?
And the extra copy from the DataSourceSurface to the shmem could maybe avoided by making a DataSourceSurface that directly wraps the shmem data?

Comment 2

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:jgilbert, could you have a look please?

For more information, please visit auto_nag documentation.