If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Improve the "canvas-2d-pixels" memory reporter

NEW
Unassigned

Status

()

Core
Graphics
3 years ago
a year ago

People

(Reporter: njn, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [MemShrink:P2])

Attachments

(1 attachment, 1 obsolete attachment)

55.78 KB, application/gzip
Details
(Reporter)

Description

3 years ago
On Mac, when scrolling through a large PDF (viewed via pdf.js) I get this from about:memory:

> 2,595.09 MB (100.0%) -- explicit
> ├──2,351.60 MB (90.62%) ── heap-unclassified

Whoa, that's a lot of heap-unclassified. But we also have this:

> 2,295.89 MB ── canvas-2d-pixels

So it's obvious that almost all of the heap-unclassified is actually canvas pixels.

Looking at the code, it's obvious why: |gCanvasAzureMemoryUsed| is the variable that tracks the amount of canvas memory in use, and there's a comment on the reporter:

// This is KIND_OTHER because it's not always clear where in memory the pixels
// of a canvas are stored.  Furthermore, this memory will be tracked by the
// underlying surface implementations.  See bug 655638 for details.

On Mac, it's clear that the pixels are stored on the heap. Can we change the reporter to reflect that?

Even better, can we measure the pixel size with a MallocSizeOf function rather than computing the size analytically? Because that would allow this reporter to integrate with DMD.

Bas, any thoughts? Are the heap blocks that hold these pixels available to us on Mac, or are they buried somewhere inside a graphics library where we can't access them?
(Reporter)

Updated

3 years ago
Flags: needinfo?(bas)
I believe they'll be allocated by Quartz currently, so I do not think we can reach them. Jeff would know better.
Flags: needinfo?(bas) → needinfo?(jmuizelaar)
(Reporter)

Updated

3 years ago
Whiteboard: [MemShrink] → [MemShrink:P2]
(In reply to Bas Schouten (:bas.schouten) from comment #1)
> I believe they'll be allocated by Quartz currently, so I do not think we can
> reach them. Jeff would know better.

They are mostly allocated by us:
http://dxr.mozilla.org/mozilla-central/source/gfx/2d/DrawTargetCG.cpp#1324

Plumbing this out to canvas will require some work though.
Flags: needinfo?(jmuizelaar)

Comment 3

3 years ago
Created attachment 8566988 [details]
Negative canvas-2d-pixels

memory_report

Comment 4

3 years ago
Created attachment 8566989 [details]
Negative canvas-2d-pixels

New (cleanup, closed some tabs)
Attachment #8566988 - Attachment is obsolete: true

Comment 5

3 years ago
I have the GC + CC logs if required? I got the idear this is caused be a substantial use of Gliffy (in clonfluence). But not sure. Will try again today to reproduce.

Comment 6

2 years ago
Right now about:memory is showing the following numbers:

1,404.38 MB ── canvas-2d-pixels
705.59 MB ── resident

and Windows Task Manager says 660 MB

canvas-2d-pixels is reporting the wrong amount.

(I'm on Windows 7 on latest Nightly and e10s off)
In bug 1241865 comment 8 I described a possible cause for this.  I think we are double counting the canvas-2d-pixels when we change canvas rendering modes.
You need to log in before you can comment on or make changes to this bug.