Open
Bug 1163367
Opened 10 years ago
Updated 2 years ago
Significant image memory regression since Fx36+ when hardware acceleration is disabled
Categories
(Core :: Graphics: ImageLib, defect, P3)
Tracking
()
NEW
People
(Reporter: dindog, Unassigned)
References
(Depends on 1 open bug, )
Details
(Keywords: memory-footprint, regression, Whiteboard: [gfx-noted])
Attachments
(1 file)
(deleted),
application/x-compress-7z
|
Details |
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
typo correction:
Reproduce process, not proceed.
3. scroll to the bottom of the page
Comment 2•10 years ago
|
||
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.
Flags: needinfo?(seth)
Comment 3•10 years ago
|
||
If i set layers.async-pan-zoom.enabled= true , I cant reproduce this.
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.
*we hold alive some decoded image data even for tabs that are closed, for 60 seconds.* from it.
Depends on: 1123976
Comment 9•9 years ago
|
||
Since this appears to be an issue with image memory, I'm moving bug from the Memory Allocator to the ImageLib Bugzilla component.
Component: Memory Allocator → ImageLib
Keywords: regressionwindow-wanted
Summary: Significant memory performance regression since Fx36+ when HA is disabled → Significant image memory regression since Fx36+ when hardware acceleration is disabled
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.
Flags: needinfo?(dindog)
Comment 11•9 years ago
|
||
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.
Hi reporter,
Did a new profile or safe mode made any difference on the latest builds?
Thanks,
Paul.
Comment 13•9 years ago
|
||
(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 .
Reporter | ||
Comment 14•9 years ago
|
||
(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?
Flags: needinfo?(dindog)
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.
Flags: needinfo?(dindog)
Reporter | ||
Comment 16•9 years ago
|
||
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.
Flags: needinfo?(dindog) → needinfo?(alice0775)
Comment 17•9 years ago
|
||
Did a new profile or safe mode made any difference?
Flags: needinfo?(dindog)
Comment 18•9 years ago
|
||
Flags: needinfo?(alice0775)
Comment 19•9 years ago
|
||
Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=66722c270acb&tochange=471b25bef3ec
Regressed by: Bug 1104622
Blocks: 1104622
Keywords: regressionwindow-wanted
Comment 20•9 years ago
|
||
/*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/
Reporter | ||
Comment 21•9 years ago
|
||
(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.
Flags: needinfo?(dindog)
Updated•7 years ago
|
Priority: -- → P3
Updated•6 years ago
|
Flags: needinfo?(seth.bugzilla)
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•