Closed Bug 615194 Opened 14 years ago Closed 14 years ago

Image Discarding does not work until tabs have been touched at least once.

Categories

(Firefox :: Tabbed Browser, defect)

Product:
Firefox
Component:
Tabbed Browser
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 4.0b8
Tracking Flags:
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: bugzilla.mozilla.org, Assigned: bzbarsky)

References

Details

(Keywords: memory-footprint)

Attachments

(2 files)

Make all new tabs not active by default, not just those with a non-blank url.
(deleted), patch
Gavin
: review+
Details | Diff | Splinter Review
test
(deleted), patch
bzbarsky
: review+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101128 Firefox/4.0b8pre Build Identifier: As discussed in bug 598466 comment 72 image.mem.discardable does not actually start discarding image memory on tabs that have not been touched after startup. On larger sessions this means a large amount of uncompressed image data needlessly stays in memory. Reproducible: Always Steps to Reproduce: 1. Create a session with many image-heavy tabs 2. restart firefox 3. watch images/content/used/uncompressed going up in about:memory 4. ctrl+tab through all tabs to visit them at least once 5. see how memory usage suddenly goes down
Blocks: 598466
This seems bad....
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Ever confirmed: true
Version: unspecified → Trunk
I would guess this has to do with the fact that docshells are active by default unless set otherwise. We probably need to set isActive to false on all the background tabs during session restoration.
Hmm. Why does addTab only set isActive = false in the !blank case?
Session restore always adds as about:blank, then does the real load.
Who's the right person to fix this?
blocking2.0: ? → betaN+
Version: Trunk → unspecified
Why are we decoding those images at all? Will setting isActive=false on the docshell cause us to avoid doing any image decoding until we switch to the tab?
(In reply to comment #6) > Why are we decoding those images at all? Will setting isActive=false on the > docshell cause us to avoid doing any image decoding until we switch to the tab? If we enable decode-on-draw, yes. See bug 573583. Should just be a pref flip... Sorry I'm not more available to drive this stuff. :\ Joe, what's your timeframe on imagelib stuff?
Attachment #494164 - Flags: review?(gavin.sharp)
Using a 70-tab testcase based on bug 598466 comment 13 on 64-bit mac, I see private bytes usage around 920MB without this patch, and around 770MB with this patch.
Assignee: nobody → bzbarsky
Component: ImageLib → Tabbed Browser
Product: Core → Firefox
QA Contact: imagelib → tabbed.browser
Whiteboard: [need review]
And I did verify that without the patch most of the tabs have docshells that are isActive, and with it they're not.
Attached patch test (deleted) — — Splinter Review
Attachment #494184 - Flags: review?(bzbarsky)
Attachment #494164 - Flags: review?(gavin.sharp) → review+
Attachment #494184 - Attachment description: testcase → test
Comment on attachment 494184 [details] [diff] [review] test r=me
Attachment #494184 - Flags: review?(bzbarsky) → review+
Pushed: http://hg.mozilla.org/mozilla-central/rev/6ec5b1133f6a http://hg.mozilla.org/mozilla-central/rev/ab7bccf8e4e4 Gavin, thanks for the test!
Status: NEW → RESOLVED
Closed: 14 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [need review]
Target Milestone: --- → Firefox 4.0b8
Memory usage on startup is down too in the latest nightly, looks good.
Keywords: footprint
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: