1163367 - Significant image memory regression since Fx36+ when hardware acceleration is disabled

Status: NEW

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

Description

[dindog]

Reproduce proceed:

1. make sure "Use hardware acceleration when available" is UNCHECKED then restart Firefox
2. open
http://www.guanggoo.com/t/3085
3. scroll to the page, observe the memory consumption of Firefox. 

Result:

Firefox 35.0.1, Maximum Mem: ~350MB 
Firefox 36.0.4, Maximum Mem: ~1090MB

Comment 1

[dindog]

typo correction:

Reproduce process, not proceed.
3. scroll to the bottom of the page

Comment 2

[Mayank Bansal]

I did a memory report, and most of it is in images.

1,092,067,392 B (100.0%) -- explicit
├──1,018,888,736 B (93.30%) -- images
│  ├──1,018,861,936 B (93.30%) -- content/raster/used
│  │  ├─────34,160,880 B (03.13%) -- image(3264x2448, http://i2.tietuku.com/2dde8df42d46f24b.jpg)
│  │  │     ├──32,923,808 B (03.01%) -- unlocked
│  │  │     │  ├──31,961,168 B (02.93%) ── surface(3264x2448@0)/decoded-heap
│  │  │     │  └─────962,640 B (00.09%) ── surface(566x424@0)/decoded-heap
│  │  │     └───1,237,072 B (00.11%) ── source
│  │  ├─────34,111,728 B (03.12%) -- image(3264x2448, http://i2.tietuku.com/0660ebb1d7734d8b.jpg)
│  │  │     ├──31,961,168 B (02.93%) ── locked/surface(3264x2448@0)/decoded-heap
│  │  │     ├───1,187,920 B (00.11%) ── source
│  │  │     └─────962,640 B (00.09%) ── unlocked/surface(566x425@0)/decoded-heap
│  │  ├─────34,046,192 B (03.12%) -- image(3264x2448, http://i2.tietuku.com/f16f004f04bc1cf7.jpg)
│  │  │     ├──32,923,808 B (03.01%) -- unlocked
│  │  │     │  ├──31,961,168 B (02.93%) ── surface(3264x2448@0)/decoded-heap
│  │  │     │  └─────962,640 B (00.09%) ── surface(566x425@0)/decoded-heap
│  │  │     └───1,122,384 B (00.10%) ── source
│  │  ├─────26,345,792 B (02.41%) -- image(2845x2134, http://i2.tietuku.com/902394c6c8d959e8.jpg)
│  │  │     ├──25,247,904 B (02.31%) -- unlocked
│  │  │     │  ├──24,285,264 B (02.22%) ── surface(2845x2134@0)/decoded-heap
│  │  │     │  └─────962,640 B (00.09%) ── surface(566x425@0)/decoded-heap
│  │  │     ├─────888,912 B (00.08%) ── locked/surface(544x408@0)/decoded-heap
│  │  │     └─────208,976 B (00.02%) ── source
│  │  ├─────26,255,680 B (02.40%) -- image(2845x2134, http://i2.tietuku.com/f87ea5722dcdd948.jpg)
│  │  │     ├──25,247,904 B (02.31%) -- unlocked
│  │  │     │  ├──24,285,264 B (02.22%) ── surface(2845x2134@0)/decoded-heap
│  │  │     │  └─────962,640 B (00.09%) ── surface(566x425@0)/decoded-heap
│  │  │     ├─────893,008 B (00.08%) ── locked/surface(544x409@0)/decoded-heap
│  │  │     └─────114,768 B (00.01%) ── source
│  │  ├─────26,227,008 B (02.40%) -- image(2845x2134, http://i2.tietuku.com/939035bf8952ae47.jpg)
│  │  │     ├──25,247,904 B (02.31%) -- unlocked
│  │  │     │  ├──24,285,264 B (02.22%) ── surface(2845x2134@0)/decoded-heap
│  │  │     │  └─────962,640 B (00.09%) ── surface(566x425@0)/decoded-heap
│  │  │     ├─────888,912 B (00.08%) ── locked/surface(544x408@0)/decoded-heap
│  │  │     └──────90,192 B (00.01%) ── source
│  │  ├─────25,583,856 B (02.34%) -- image(2845x2134, http://i2.tietuku.com/a96a2c946dfbb9ba.jpg)
│  │  │     ├──25,247,904 B (02.31%) -- unlocked
│  │  │     │  ├──24,285,264 B (02.22%) ── surface(2845x2134@0)/decoded-heap
│  │  │     │  └─────962,640 B (00.09%) ── surface(566x425@0)/decoded-heap
│  │  │     └─────335,952 B (00.03%) ── source
│  │  ├─────25,559,280 B (02.34%) -- image(2845x2134, http://i2.tietuku.com/2c4dafc3b2e2c7bf.jpg)
│  │  │     ├──25,247,904 B (02.31%) -- unlocked
│  │  │     │  ├──24,285,264 B (02.22%) ── surface(2845x2134@0)/decoded-heap
│  │  │     │  └─────962,640 B (00.09%) ── surface(566x424@0)/decoded-heap
│  │  │     └─────311,376 B (00.03%) ── source
│  │  ├─────25,506,032 B (02.34%) -- image(2845x2134, http://i2.tietuku.com/48c50f388acd753b.jpg)
│  │  │     ├──25,247,904 B (02.31%) -- unlocked
│  │  │     │  ├──24,285,264 B (02.22%) ── surface(2845x2134@0)/decoded-heap
│  │  │     │  └─────962,640 B (00.09%) ── surface(566x425@0)/decoded-heap
│  │  │     └─────258,128 B (00.02%) ── source

and so on.

This mostly seems to be related to imagelib. Tentatively ni? seth.

Comment 3

[Mayank Bansal]

If i set layers.async-pan-zoom.enabled= true , I cant reproduce this.

Comment 4

[YF (Yang)]

I reproduce the bug on Fx36 & Fx41, not for Fx35 & Fx41 with layers.async-pan-zoom.enabled=true. The same result.

I see the huge memory is automatically cleaned up after ~1min, to 161/234MB (working set/virtual memory), then 150/208MB. also cleaned up after "minimize memory" in about:memory.

Comment 5

[YF (Yang)]

*we hold alive some decoded image data even for tabs that are closed, for 60 seconds.* from it.

Comment 7

[xunxun]

Try to set image.mem.surfacecache.min_expiration_ms to 1000

Comment 8

[FateRover]

verified 45.0.1

Comment 9

[Chris Peterson [:cpeterson]]

Since this appears to be an issue with image memory, I'm moving bug from the Memory Allocator to the ImageLib Bugzilla component.

Comment 10

[Paul Pasca[Away. Please needinfo? Paul Oiegas [:pauloiegasSV]]]

Hi reporter,

I have tested your issue on latest FF release (45.0.2) and latest Nightly build and could not reproduce it. I have unchecked "Use hardware acceleration when available" and after a restart, the browser didn't use more than 300 MB of memory(several tabs where opened). Firefox had the same behavior regardless if "layers.async-pan-zoom.enabled" was set to true or false.

Is this still reproducible on your end ? If yes, can you please retest this using latest FF release and latest Nightly build (https://nightly.mozilla.org/) and report back the results ? When doing this, please use a new clean Firefox profile, maybe even safe mode, to eliminate custom settings as a possible cause (https://goo.gl/PNe90E).

Thanks,
Paul.

Comment 11

[Timothy Nikkel (:tnikkel)]

I tested these are the numbers I see:

Firefox 35.0.1, Maximum Mem: ~600MB 
Firefox 36.0.4, Maximum Mem: ~1600MB
Current Firefox nightly, ~1000MB

So we regressed, and then improved, but didn't fix all of the regression.

Comment 12

[Paul Pasca[Away. Please needinfo? Paul Oiegas [:pauloiegasSV]]]

Hi reporter,

Did a new profile or safe mode made any difference on the latest builds?

Thanks,
Paul.

Comment 13

[FateRover]

(In reply to Timothy Nikkel (:tnikkel) from comment #11)
> I tested these are the numbers I see:
> 
> Firefox 35.0.1, Maximum Mem: ~600MB 
> Firefox 36.0.4, Maximum Mem: ~1600MB
> Current Firefox nightly, ~1000MB
> 
> So we regressed, and then improved, but didn't fix all of the regression.

that strange, i test it on ff45.0.2,i cant reproduce it whether HA is on or off .

Comment 14

[dindog]

(In reply to Paul Pasca[:PoollyMcklayn] from comment #12)
> Hi reporter,
> 
> Did a new profile or safe mode made any difference on the latest builds?
> 
> Thanks,
> Paul.

I got some new discovery.  Not sure it should be discuss in a new bug report....

Test with the Nightly 48a1 2016-04-21 on Win10 64bit.

I didn't reproduce the bug at first, then I resized the frame of Firefox, the memory allocated to Firefox bumped up quickly, a few second later it reach 1100MB. CPU usage was high as well

This website will scale the image to fit the width of browser window, maybe Firefox try to resample the resized image in too small interval, GPU can take care it but not the case when it come to CPU?

Comment 15

[Paul Pasca[Away. Please needinfo? Paul Oiegas [:pauloiegasSV]]]

Hi reporter,

I'm still unable to reproduce your issue with the steps from your latest comment. Did a new profile or safe mode made any difference? If you are still reproducing this issue, could you please try to find a regression range using Mozregression tool?
Information on the tool is available at http://mozilla.github.io/mozregression/. Please don't hesitate to contact us if you encounter any problems.

Thanks,
Paul.

Comment 16

[dindog]

What do you mean can't reproduce the issue, you didn't have noticeable RAM different between 35.0.1 from later versions or the hardware acceleration part? 

It's easy reproduce

firefox -no-remote -safe-mode -profile d:\new_profile

Open the page, wait all image loaded, scroll to have some images into view, then resize Firefox windows, then Firefox CPU usage and memory consumption bump up quickly which you can't hardly notice it, it rise to over 1000MB in 20 second.

I am afraid using mozregression tool is not an option for me at them moment... My connection to mozilla ftp has been bad recently, nightly stay at April 22nd...

I hope Alice could reproduce it... he has been really good at locating regression commit.

Comment 17

[Andre Klapper]

Did a new profile or safe mode made any difference?

Comment 18

[Alice0775 White]

Attachment: archive

Comment 19

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=66722c270acb&tochange=471b25bef3ec

Regressed by: Bug 1104622

Comment 20

[FateRover]

/*the last version with well perfomance (resize widows or scrool the page wont lead memory grown)*/
Dir 	2014-11-28-00-40-01-mozilla-aurora/ 	
	
/*not contain windows installer or zip */ 	
Dir 	2014-11-28-08-00-45-mozilla-aurora/
 		
/*not contain windows installer or zip */
Dir 	2014-11-28-08-05-23-mozilla-aurora/ 	
	
/*the first version with bad perfomance (resize widows or scrool the page will lead memory grown)*/ 
Dir 	2014-11-28-11-51-36-mozilla-aurora/

/*the last version with bad perfomance (resize widows or scrool the page will lead memory grown)*/ 
Dir 	2015-12-14-00-40-08-mozilla-aurora/

/*the first version fixed the bug PARTLY(resize widows will lead memory grown but scrool the page wont as Comment 14 )*/ 
Dir 	2015-12-14-12-22-42-mozilla-aurora/

Comment 21

[dindog]

(In reply to Andre Klapper from comment #17)
> Did a new profile or safe mode made any difference?
No. It's tested with new profile and safe mode.

Sorry for the late reply, not available in weekdays. And thanks to Alice and FateRover narrowed down the commits.