1157559 - Huge memory use on https://testdrive-archive.azurewebsites.net/Graphics/VideoPanorama/Default.html

Status: RESOLVED FIXED

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

Description

[Mayank Bansal]

Attachment: 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.

Comment 1

[Timothy Nikkel (:tnikkel)]

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).

Comment 2

[Seth Fowler [:seth] [:s2h]]

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.

Comment 3

[Seth Fowler [:seth] [:s2h]]

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.

Comment 4

[Mayank Bansal]

Attachment: memory-report.json.gz

this is with bug 1157954 fixed.
I have e10s enabled.

Comment 5

[Bas Schouten (:bas.schouten)]

Seth, is this won't fix or do we plan to improve this somehow?

Comment 6

[Mayank Bansal]

possibly related : bug 1163367

Comment 7

[Seth Fowler [:seth] [:s2h]]

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.

Comment 9

[Mayank Bansal]

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


reopening.

Comment 10

[Mayank Bansal]

Attachment: memory-report.json.gz

about:memory on a fresh profile on the latest nightly.

Comment 11

[Mayank Bansal]

doesnt happen anymore