590100 - [D2D] Memory spike in AeroPeek Taskbar Previews

Status: RESOLVED INCOMPLETE

(Core :: Graphics, defect)

Description

[Jim Jeffery not reading bug-mail 1/2/11]

Attachment: about:memory screen cap w/taskmanger

From bug 513681 https://bugzilla.mozilla.org/show_bug.cgi?id=513681#c52
(In reply to comment #51)
> I don't know if its something to worry about, but I can still repo the memory
> spike with the updated patch and re-landing. 
> 
> I currently have 11 tabs open:
> MSNBC, CNN, MZ forum, http://ftp hourly builds, tbpl, digg.com, neowin.net
> Landing que page, and 3 bugzilla pages.
> 
> On startup of the browser I let the UI stabilize, and the throbbers on the tabs
> stop spinning.  I then immediately go to the Minefield icon in the taskbar and
> mouse over to activate 'aero-peek', (taskbar previews) - then watching the
> taskmanager I see the working memory, and peak memory start to climb with the
> peak working hitting over 1gig, last start up with this procedure hit 1.4gig. 
> After a a min or two, working falls to what is somewhat 'normal' for my tabs,
> around 250meg-300meg.  
> 
> So far, I've not noticed any performance or browser issues but I've not let it
> run for any extended period of time, trying to verify what I'm seeing. 
> 
> If it start the browser with the tabs listed, and wait for 2-3 minutes before
> mousing over the taskbar icon to activate the previews - the memory jumps some,
> but anywhere near the levels seen when activating the previews immediately
> after startup. 
> 
> Turning off d2d again resolves the huge spike in memory use problem.

This is for follow up investigation.

STR:
Open up to 10-11 tabs, or use tab-set above.  
Start the browser and watch with Taskmanager
As soon as the UI loads - mouse over the Icon for Minefield in the Taskbar and leave the cursor there while the tabs load, keeping an eye on the TaskManager.
Note that some short period of time after the tabs load that memory use starts to climb often going over 1gig in Peak Memory column.  The Working Memory will cycle upward and reset, and cycle upward and reset in a continuous cycle.

Comment 1

[Joe Drew (not getting mail)]

This has nothing to do with imagelib.

Comment 2

[Bobby Holley (:bholley)]

(In reply to comment #1)
> This has nothing to do with imagelib.

Well, Jim says that this started happening with superclass. Not sure if that's incidental though.

I wonder if it means we started doing something stupid with memory that triggered bug 589809 faster? If so, maybe we should look into it. Joe, you know more about d2d than I do - thoughts?

Comment 3

[Bobby Holley (:bholley)]

Also, FWIW the aero peek previous are canvas.

Jim, are you absolutely 100% sure that this started happening with bug 513681 (landed on saturday night, relanded on sunday night), and not bug 563088? Bug 563088 would make a hell of a lot more sense.

Comment 4

[Jim Jeffery not reading bug-mail 1/2/11]

(In reply to comment #3)
> Also, FWIW the aero peek previous are canvas.
> 
> Jim, are you absolutely 100% sure that this started happening with bug 513681
> (landed on saturday night, relanded on sunday night), and not bug 563088? Bug
> 563088 would make a hell of a lot more sense.

Yes, I tested with hourly builds before and with your checkin.  When it landed I saw the problem, but not before, and every build after that shows the problem.  When it was backed out, I can confirm that the build with the backout also did not display the problem, and reappeared when it landed again.

Comment 5

[Jim Jeffery not reading bug-mail 1/2/11]

Testing over past few days I've found that setting pref layers.accelerate-none to 'true' seems to prevent the large leaps in memory when mousing over the icon in the taskbar.

Comment 6

[Rob Arnold [:robarnold]]

Attachment: WIP

Here's my plan for fixing this (copy & pasted from IRC, minor formatting):

Now that 130078 has landed, drawWindow on the top level window will paint the
tab contents so we don't need to keep around that large canvas for drawing the
tab contents quickly.  We can instead keep around the smaller canvas which is
thumbnail sized. Now, the thumbnail sizes may vary so we have to check that the
requested thumbnail size matches our cached thumbnail and the incremental
update code needs to do the right math.

Thumbnails are usually 200x120 pixels so they're rather cheap to keep around.
I think we can cache them for a long time and not feel guilty. Each thumbnail
is ~100k and we have at most 20.

Shouldn't take more than a few hours of JS hacking I'd guess but I really
shouldn't take time off to do this right now. Someone can feel free to steal
this from me. I already have the "don't draw the tab content" bit working as a
simple PoC (attached).

Comment 7

[u279076]

I am closing this as INCOMPLETE since I cannot reproduce this bug. Please reopen if you can still reproduce this.