Joe tells me that decode-on-draw and decoded image discard is currently disabled. This is bad.

This blocks _a_ beta, but not necessarily beta 1.

taking.

changed this bug to be just about re-enabling discarding, which we should do first and make sure there are no problems. I've filed bug 573583 for decode-on-draw.

I just wanted to chime in to say this was actually the _only_ bug that negatively affected my browsing after testing 3.7alpha5 for about a week -- including getting an array of about 20 extensions to to work flawlessly! It's really the only thing keeping me from using the alpha full-time (and undoubtedly being a better alpha-tester), since a single image-intensive tab could easily bump the working memory up to a gigabyte or more (ouch). I am still learning the semantics of proper bug-filing but I would vote for this blocking any beta release, since it actually renders Firefox unusable in many circumstances.

(In reply to comment #5) > I just wanted to chime in to say this was actually the _only_ bug that > negatively affected my browsing after testing 3.7alpha5 for about a week -- > including getting an array of about 20 extensions to to work flawlessly! It's > really the only thing keeping me from using the alpha full-time (and > undoubtedly being a better alpha-tester), since a single image-intensive tab > could easily bump the working memory up to a gigabyte or more (ouch). > > I am still learning the semantics of proper bug-filing but I would vote for > this blocking any beta release, since it actually renders Firefox unusable in > many circumstances. I'm working on it. It won't be in beta 1, but it should be in beta 2. Glad to hear people care about this. ;-)

This seems to work very well memory usage is finally sane , but it causes 50% cpu usage after 2/3 mins of usage browsing sites like facebook or neowin. Closing the browser doesn't kill the process and firefox is still stuck at 50% cpu usage until i manually kill the process via taskmanager. I'm on windows 7 X64

(In reply to comment #7) > This seems to work very well memory usage is finally sane , but it causes 50% > cpu usage after 2/3 mins of usage browsing sites like facebook or neowin. > Closing the browser doesn't kill the process and firefox is still stuck at 50% > cpu usage until i manually kill the process via taskmanager. I'm on windows 7 > X64 Myzar - Can you clarify what you're talking about? This bug hasn't been fixed yet.

I've enabled image.mem.decodeondraw & image.mem.discardable in about:config for a test drive and i've experienced the 50% cpu usage , sorry if this is known already i thought it would be usefull to report before you enable it by default

(In reply to comment #9) > I've enabled image.mem.decodeondraw & image.mem.discardable in about:config for > a test drive and i've experienced the 50% cpu usage , sorry if this is known > already i thought it would be usefull to report before you enable it by default Ah, I see. I suspect this might be related to bug 502694. Can you keep an eye on that bug and give this another shot (maybe with _only_ image.mem.discardable) once that lands?

sure i will

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100701 Minefield/4.0b2pre I just tested today Minefield (20100701, so before bug 502694 was checked in) with image.mem.decodeondraw & image.mem.discardable set ; and with only image.mem.discardable set. Note that there still are separate timer per image. The behavior between both was the same ; I saw memory blocks appearing in the *raw fields of about:memory (is 0 when you didn't use either setting) wen content was loaded, and in */uncompressed I saw blocks appearing when drawn and disappearing when they were discarded. That is : you don't need image.mem.decodeondraw to discard memory. I saw the 50% cpu usage with in both configurations. But sometime it took only a minute to see it, sometimes I had to surf for 20 minutes or so (I originally thought that it was due to image.mem.decodeondraw, but I repeated the test many times). It's not clear what triggered it, but I didn;t see it when both settings are false. I'm going to test again tomorrow, when there's single timer, to see if there's a difference (a bit faster I suppose).

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100702 Minefield/4.0b2pre I still see the 50% cpu-load, with both preferences. But it took a very long time before I saw it with only image.mem.discardable set (30 minutes). It's reproducible, but it can take a long time.

Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:2.0b2pre) Gecko/20100702 FireFox/3.6 Same Here , it happened after 16mins . Facebook seems to particularly trigger it but not at will

I've filed bug 576615 for the 50% cpu issue - let's move the discussion there.

I've ran it and this is the trace , but i've no idea about how to read it

I've run the browser for a while with image.mem.discardable now that the 50% cpu usage is fixed and i've noticed that favicons in my bookmark sidebar keep flickering every 2/3 mins, it's like favicons images are discarded and refetched they go blank for a second. They shouldn't be discarded considering the small size and the fact that they are always displayed in the sidebar

(In reply to comment #17) > I've run the browser for a while with image.mem.discardable now that the 50% > cpu usage is fixed and i've noticed that favicons in my bookmark sidebar keep > flickering every 2/3 mins, it's like favicons images are discarded and > refetched they go blank for a second. They shouldn't be discarded considering > the small size and the fact that they are always displayed in the sidebar This should be fixed by bug 511899.

Will this be enabled in Core? Re-enable image discarding will crash Thunderbird. STR: Enable image.mem.discardable in TB --> Open a mail with one or more attachments --> Go to "File" -> "Attachments". TB will crash immediately. (Tested on Mac OS X with TB trunk)

(In reply to comment #19) > Will this be enabled in Core? Re-enable image discarding will crash > Thunderbird. > STR: Enable image.mem.discardable in TB --> Open a mail with one or more > attachments --> Go to "File" -> "Attachments". TB will crash immediately. > (Tested on Mac OS X with TB trunk) It will. Please file a bug with a crash stack and CC me - I'll look into it.

This blocks beta 5, aka the feature freeze.

We need to make sure that things doing live preview, specifically aero peek and tabcandy, aren't broken by this.

Requesting the rubber-stamp review from joe.

Pushed to mozilla-central: http://hg.mozilla.org/mozilla-central/rev/33be08836cb1 Optimistically resolving fixed.