1748120 - AWFY page can take 5-6GB of RAM, and 1GB+ as heap unclassified in content process

Status: RESOLVED FIXED

(Core :: Graphics: Canvas2D, defect)

Description

[Mayank Bansal]

Attachment: memory-report.json_not_accelerated.gz

enable accelerated canvas
go to https://arewefastyet.com/win10/benchmarks/raptor-desktop-jetstream2?numDays=60

let the page load

ER: Nightly uses 200-300 MB RAM (as it does with un-accelerated canvas)
AR:

1. 5-6GB RAM in the GPU process. 700MB as heap unclassified
2. 1.3GB RAM use in the content process, with 1.2GB as heap unclassified.

Comment 1

[Mayank Bansal]

Attachment: accelerated_memory-report.json.gz

Comment 2

[Mayank Bansal]

Attachment: about:support

Comment 3

[Dzmitry Malyshau [:kvark]]

Enabling accelerated canvas and visiting this page on the current Nightly on macOS just crashed the browser after 10 seconds (of loading the page).
So this is nasty. However, since it only happens when you manually enable accelerated canvas, it's not urgent (and you already blocked gpu-canvas, thank you!). Added another 2 bugs in See Also that look similar.

Comment 5

[Mayank Bansal]

Attachment: memory-report.json.gz

PID 20624 and PID 16972

Comment 6

[Mayank Bansal]

Hi Lee. With Nightly as of https://hg.mozilla.org/mozilla-central/rev/c59c06e50b89ab3772d032e6a2344abbd505fe0d , I can still repro this bug.
If I open the link, let the page load, scroll up and down a few times, and refresh the page, the memory in GPU process reaches 1.3GB and heap unclassified in content process reaches 1.2GB.

Should this bug be unduped ?

Comment 7

[Lee Salzman [:lsalzman]]

Okay, undup it. Can you submit a new memory report with my fixes from nightly in it so I can look to see if anything changed?

Comment 8

[Mayank Bansal]

The memory report is attached in comment #5

Comment 9

[Mayank Bansal]

This improved quite a bit recently.

Bug 1777872 - Use Shmem for backing DrawTargetWebgl's Skia target. r=jgilbert

When rendering large and/or fullscreen Canvas2Ds, excessive time can be spent
in calls to TexImage/ReadPixels copying into and out of Shmems to the separate
buffer for DrawTargetSkia. To alleviate this, we can make the DrawTargetSkia
directly wrap the Shmem, so that calls to TexImage/ReadPixels then directly
read or write to this without any separate copy. We modify RawTexImage to use
the IPDL SendTexImage path so that Shmems can be sent via SurfaceDescriptor.
Since SendTexImage is nominally async (which is beneficial), we rely on a
call to GetError later to verify that the Shmem processing is completely before
we further modify the DrawTargetSkia. We further add a ReadPixelsIntoShmem IPDL
call to allow sending the Shmem in the other direction directly.

Differential Revision: https://phabricator.services.mozilla.com/D151286

2022-07-29T08:29:42.438000: DEBUG : Did not find a branch, checking all integration branches
2022-07-29T08:29:42.447000: INFO : The bisection is done.
2022-07-29T08:29:42.449000: INFO : Stopped