RESOLVED FIXED

Status

()

P3
normal
RESOLVED FIXED
4 years ago
3 months ago

People

(Reporter: mayankleoboy1, Unassigned)

Tracking

(Depends on: 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [gfx-noted], URL)

Attachments

(3 attachments)

(Reporter)

Description

4 years ago
Created attachment 8596341 [details]
memory-report.json.gz

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150422030206

Steps to reproduce:

1. go to http://ie.microsoft.com/testdrive/Graphics/VideoPanorama/Default.html 
2. do the side-to-side pan thingy 5-6 times.
3. Measure the memory use with Windows Task Manager.


Actual results:

Memory grows to 1.4GB, and then stabilizes


Expected results:

probably not so.

The memory is released if you do "minimize memory".  And if you navigate to a new tab, the memory is released in about 30 seconds.
This image http://ie.microsoft.com/testdrive/Graphics/VideoPanorama/thumbnails/ToyStory3_HTML5.jpg (about 900x500 pixels) ends up taking 170mb in it's decoded size. I'm guessing that can't be for one copy of the image. We must be keeping around one decoded copy for every size that every image is displayed at (they are animated from big to small and back).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(seth)
Hmm, but how? Without DDD, we don't decode different versions of the image for different sizes, so I wouldn't expect multiple SurfaceCache entries for the same image in this testcase.

I'm wondering whether we're not somehow missing in the ImageLib cache and actually creating a different RasterImage object for each point in the animation. I don't think that'd be visible in about:memory, because duplicate paths in the tree get merged (AFAIK).

I'm making a build with some custom logging to investigate now.
Flags: needinfo?(seth)
Heh, actually, of course there's HQ downscaling. <smacks forehead>

That's probably what's happening here. These images probably aren't getting layerized, and so we're probably ending up with HQ downscaled versions for every point in the animation.
See Also: → bug 1157954
(Reporter)

Comment 4

4 years ago
Created attachment 8600588 [details]
memory-report.json.gz

this is with bug 1157954 fixed.
I have e10s enabled.
Seth, is this won't fix or do we plan to improve this somehow?
Flags: needinfo?(seth)
Whiteboard: [gfx-noted]
(Reporter)

Comment 6

4 years ago
possibly related : bug 1163367
It's definitely *not* wontfix. I'd like to fix this during the 41 cycle if possible. It requires that we rate limit high-quality downscaling of images, which is a known issue.
Flags: needinfo?(seth)
Depends on: 1169060
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1370412
(Reporter)

Comment 9

a year ago
This has not been fixed in the latest nightly  https://hg.mozilla.org/mozilla-central/rev/a20de99fa3c1ba6287fe47d493a859a4e95120b0


reopening.
Status: RESOLVED → REOPENED
Flags: needinfo?(aosmond)
Resolution: DUPLICATE → ---
(Reporter)

Comment 10

a year ago
Created attachment 8910319 [details]
memory-report.json.gz

about:memory on a fresh profile on the latest nightly.
(Reporter)

Updated

3 months ago
Flags: needinfo?(aosmond)
(Reporter)

Updated

3 months ago
Summary: Huge memory use on http://ie.microsoft.com/testdrive/Graphics/VideoPanorama/Default.html → Huge memory use on https://testdrive-archive.azurewebsites.net/Graphics/VideoPanorama/Default.html
(Reporter)

Comment 11

3 months ago
doesnt happen anymore
Status: REOPENED → RESOLVED
Last Resolved: a year ago3 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.