563088 - re-enable image discarding

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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

Comment 1

[Joe Drew (not getting mail)]

This blocks _a_ beta, but not necessarily beta 1.

Comment 2

[Bobby Holley (:bholley)]

taking.

Comment 3

[Bobby Holley (:bholley)]

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.

Comment 5

[Adam]

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.

Comment 6

[Bobby Holley (:bholley)]

(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. ;-)

Comment 7

[Myzar]

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

Comment 8

[Bobby Holley (:bholley)]

(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.

Comment 9

[Myzar]

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

Comment 10

[Bobby Holley (:bholley)]

(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?

Comment 11

[Myzar]

sure i will

Comment 12

[Jo Hermans]

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).

Comment 13

[Jo Hermans]

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.

Comment 14

[Myzar]

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

Comment 15

[Bobby Holley (:bholley)]

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

Comment 16

[Myzar]

Attachment: Performance Profiling

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

Comment 17

[Myzar]

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

Comment 18

[Bobby Holley (:bholley)]

(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.

Comment 19

[Nomis101]

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)

Comment 20

[Bobby Holley (:bholley)]

(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.

Comment 21

[Joe Drew (not getting mail)]

This blocks beta 5, aka the feature freeze.

Comment 22

[Bobby Holley (:bholley)]

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

Comment 23

[Bobby Holley (:bholley)]

Attachment: patch

Requesting the rubber-stamp review from joe.

Comment 24

[Bobby Holley (:bholley)]

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

Optimistically resolving fixed.