Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007101609 Minefield/3.0a9pre ID:2007101609 repro: open FF and open a few tabs open a few other apps and play around a bit bring FF to the foreground (focus) result: it takes 5 -10 seconds before the app and content are painted. The problem went away when Bug 296818 was backed out to investigate bug 399955

right Bug 296818 was relanded and the problem is back. This is only visable if you use a sidebar, doesn't matter if it's the places sidebar, history sidebar or in my case the sidebar from the tabsidebar extension.

the presence of a sidebar makes it worse, but the problem is noticeable with the standard window aswell, possibly caused by the images in the bookmarks toolbar. (The images in the sidebars seem to be the cause too) btw i'm using XP on a T5600 duo , Ati X1450 and 2Gb of ram.

It seems you need to browse a while first, apparently to make sure all the memory is filled. After that even if you use a single tab the delay is noticeable.

Is anyone else seeing this? It shouldn't be 5-10 seconds to redecode...

I open my 5 regular tabs with: http://forums.mozillazine.org/ https://mail.google.com/mail/ http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&filetype=match&whotype=match&sortby=Date&hours=2&date=day&cvsroot=%2Fcvsroot http://hourly-archive.localgho.st/win32.html browse a few minutes (visit forumposts, check mail,click some links on the archive). Open any other app and bring FF back to the foreground

maybe this is a problem for laptops only that use the normal ram for graphics aswell. I have been using a new profile for a few days just to see if it might be profile and/or extension related, it's not. After 10-15 minutes of use, FF simply sux. Even switching between tabs and opening/closing tabs takes up to 5 secs. If a closed tab contains animated flash the delay goes up to nearly 10 secs.

this should be blocking if people are seeing it... unfortunately I can't reproduce it on any of my machines :(

settings: gfx.color_management.enabled true gfx.color_management.display_profile C:\\WINDOWS\system32\spool\drivers\color\kodak_dc.icm once i disable the colormanagement the problem is gone.

I'm not sure this should be blocking Bug 16769 or not ?

Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9b3pre) Gecko/2007122815 Minefield/3.0b3pre Bug does not seem to be affecting me. Last statement on this bug was 6 weeks ago: other platforms re-check?

That's because my graph chip died, so can't test the problem

I can still see this problem with the 2008-01-10 trunk build. 1. gfx.color_management.enabled -> true; ...display_profile -> "" (=sRGB) 2. visit e.g. http://www.physics.drexel.edu/~goldberg/projections/ 3. scroll right down so pictures are out of sight, wait for a while 4. press Page Up a few times: each step takes 5-10 seconds 5. switch to this bug in another tab, wait for a while. 6. selecting the original tab takes about 10 seconds. If I set color_management.enabled -> false, steps 4 and 6 are both basically instant, maybe a tiny bit lumpy. System: 384MB P3-600, about 80-100MB physical RAM free; GeForce 256 32MB; WinXP; Comodo Firewall/AV.

going to minus this since we aren't shipping with color correction on by default -- we'd like to fix this but can't easily reproduce it. we know littlecms needs to be made a bit faster and we'll likely do that in the next release

I found this bug obviously, when the windows explorer copying the huge files took the 100% CPU resources. It's easy switching to other apps, or starting another explorer. But Fx takes a few seconds to bring it back to the foreground. Even I have the Pentium 4 2.4GHz /w HT, 1G RAM and GeForce Fx5500(128MB) on WinXP SP2. Generated: Sat Mar 15 2008 08:24:15 GMT+0800 User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031412 Minefield/3.0b5pre

See forum thread: http://forums.mozillazine.org/viewtopic.php?f=7&t=688285 Firefox aggressively frees decompressed images after only about 15 seconds, even with the tabs open and the user still on the page. This introduces some lag when scrolling or switching tabs. As noted above, the problem is greatly exacerbated by turning on color management, as this appears to reduce decompression performance by 10x for some larger images. See https://bugzilla.mozilla.org/show_bug.cgi?id=435628 for more details, and http://qucs.sourceforge.net/tech/node101.html for some good example images. I suggest that the algorithm for reclaiming memory needs to be tweaked to hold image data longer for open tabs, and still longer for the tab currently being viewed. This will improve apparent performance with and without the color management problem, and should still avoid the appearance of memory leaks.

If the bahavior is based upon the fact that firefox drops the uncompressed image after only a few seconds adding a setting (e.g about:config) can help to improve it for people which deal regularly with large images. For the future i would implement a learning algorithm which increases the timeout when images often need to be uncompressed.

I'm seeing this issue with http://www.starcraft2.com/features/planets/char.xml

Confirmed. I ran into this issue while doing some other perf analysis on CM. If I leave the app in the background for a while with a big CMed imaged loaded, it takes a noticeable amount of time. I managed to Shark it, and it looks like it spent about 50% of that time redoing all the matrix multiplication and interpolation for color management, 8.4% in jpeg_idct_islow, 8.1% in the vector operation from DrawImage, 7.2% in decode_mcu (jpeg_read_scanlines), and 3% in ycc_rgb_convert (jpeg_read_scanlines). Stuart - does this mean it's doing all the image decoding again? Is this the expected result of our caching policy? This problem should be helped by my work on bug 444661, which should get rid of nearly half of that 50% color management overhead (LUT interpolations). The matrix multiplications may be much more difficult to deal with though. Editing this bug so that it shows up under the perf regression bug for CM.

CCing Joe given his work on image caching

This is just a known side effect of our old discarding strategy. This should be fixed by the stuff over in bug 435296 once we eventually get discarding switched back on. Resolving fixed.