666560 - The best way to handle images

Status: RESOLVED DUPLICATE of bug 661304

(Core :: Graphics: ImageLib, defect)

Description

[Jake]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:7.0a1) Gecko/20110618 Firefox/7.0a1
Build Identifier: 

Opening a page containing too many pictures using Fx is a disaster.
try this page:
http://www.gcforum.org/viewthread.php?tid=5721
Just open it and do nothing, no scrolling no moving, then open taskmgr to see how much memory it will consume, staggering 1.5G, if you don't have that much spare memory, Fx will simply crash.
Maybe you don't care, you have 8G ram, but when you switch to other tabs for a while (depending on image.mem.min_discard_timeout_ms) then switch back, Fx will freeze, nobody in his right mind would still think it's acceptable.
Problem is we only saw one picture on that page, maybe we are only interested in this one, and we will never see the rest of it. why decode all the pictures throwing them all into memory?
If we only decode pictures in screen sight, all the problems will be solved.
I think the best way to do it is: when a picure's been in screen sight over 0.5s, decode it, when over 1s, predecode the next picture not in screen sight,this way when you drag the scroll bar very quickly from top to bottom,the pictures in between will not be decoded,it's not your intention to see them. the only way Fx will decode all the pictures is when you slowly scroll the page to see all the pictures one by one.
When you switch to other tabs, Fx can discard all decoded images immediately to save memory, even if you switch back immediately, it will cause no slowdown becuase Fx will only redecode the picture in sight.

Reproducible: Always

Comment 1

[Jake]

Here is another advantage: even if you've viewed all the pictures, all the pictures have been decoded into memory, eventually you will stay at the part you are most interested in, then you can simply switch to another tab then switch back, all the decoded images will be discarded and only the pictured you stay at will be redecoded, then a significant amount of memory will be saved.

Comment 2

[Jo Hermans]

That's decode-on-draw (bug 573583). However, at this moment it's only used but background tabs (see bug 573583 comment 3).

Comment 4

[Jake]

(In reply to comment #2)
> That's decode-on-draw (bug 573583). However, at this moment it's only used
> but background tabs (see bug 573583 comment 3).

They are apparently not the same. first of all, "not decode images loaded in background tabs" doesn't work, just open this link in a background tab see how much memory it will take.
http://www.gcforum.org/viewthread.php?tid=5721
My idea introduced a new concept called "in sight", like Matt Brubeck said in this link "we'll need more infrastructure" 
https://bugzilla.mozilla.org/show_bug.cgi?id=664290
Are you telling me just turn on "decode-on-draw" all the problems I described will disappear? Don't try to simplify it to avoid responsibility. I know it may not be easy, but you should at least acknowledge it.

Comment 5

[Jo Hermans]

The purpose is to delay the decoding process (which blows up the image to its uncompressed size) until the image becomes visible. That is true for all images that are not visible on the screen (scrolled away, or in a background tab. The image itself will be present in memory though (see the 'raw' and 'uncompressed' items in <about:memory>).

When I set the image.mem.decodeondraw preference to true, and open that link in the background, I have 70 MB of images in memory. When I switch to tab, it will however immediately explode to over 1.2GB, because all the images will decoded. Note that this takes a long time (that's one of the reason that decode-on-draw is not the default setting at the moment). When I switch back to a different tab, it's back at 80MB.

Note that there's still a lot to improve, all images on the tab are now decoded all at once, not only the ones visible on the screen.  That a result of the same algorithm that locks all front-tab images in memory, which prevents decode-on-draw to work on front-tabs. They did it for performance reasons (you could see images decodinmg on the fly when you scrolled thru a long page), but it's horrible on websites like this. There were some suggestions in bug 660577 to optimize this (decode images that are just outside of your window, but not the rest of the page).

Comment 6

[Nicholas Nethercote [inactive]]

Jake, take a look at bug 660577, which is all about problems with image-heavy sites.

Comment 7

[Jake]

(In reply to comment #5)
> The purpose is to delay the decoding process (which blows up the image to
> its uncompressed size) until the image becomes visible. That is true for all
> images that are not visible on the screen (scrolled away, or in a background
> tab. The image itself will be present in memory though (see the 'raw' and
> 'uncompressed' items in <about:memory>).
> 
> When I set the image.mem.decodeondraw preference to true, and open that link
> in the background, I have 70 MB of images in memory. When I switch to tab,
> it will however immediately explode to over 1.2GB, because all the images
> will decoded. Note that this takes a long time (that's one of the reason
> that decode-on-draw is not the default setting at the moment). When I switch
> back to a different tab, it's back at 80MB.
> 
> Note that there's still a lot to improve, all images on the tab are now
> decoded all at once, not only the ones visible on the screen.  That a result
> of the same algorithm that locks all front-tab images in memory, which
> prevents decode-on-draw to work on front-tabs. They did it for performance
> reasons (you could see images decodinmg on the fly when you scrolled thru a
> long page), but it's horrible on websites like this. There were some
> suggestions in bug 660577 to optimize this (decode images that are just
> outside of your window, but not the rest of the page).

I thought "decodeondraw in background" was already in effect without turning on "image.mem.decodeondraw",my mistake. "not only the ones visible on the screen are decoded" means "drawing" is not exact the same with "in sight",simply duplicating it is a bit arbitrary, don't you think?
"you could see images decodinmg on the fly when you scrolled thru a long page" but not this page, which means this page is at fault? but Fx can be improved to accommodate a "faulty" page like this? but it has nothing to do with "decodeondraw" because "you could see images decodinmg on the fly when you scrolled thru a long page" without turning on "image.mem.decodeondraw", is it right?

Comment 8

[Jake]

(In reply to comment #6)
> Jake, take a look at bug 660577, which is all about problems with
> image-heavy sites.

Thanks. Now I think the best (temporary) solution is that set "image.mem.min_discard_timeout_ms" to "never" and never use Fx to open a page with too many pictures, if you accidentally open one, immediately close it. but here is my concern,if I set "image.mem.min_discard_timeout_ms" to "never"(or a very high number) when I close a tab, how long will it take to discard docoded images? is it also determined by "image.mem.min_discard_timeout_ms"?
Let me put it this way,when I switch tabs, I don't want docoded images to be discarded, Im willing to sacrifice some memory in exchange for smoothness, but when I close a tab, I want docoded images to be discarded to save memory, is it possible?

Comment 9

[Jake]

I don't know why after I replied, the status changed, It wasn't my intention to do that.

Comment 10

[Jake]

I filed this bug, please take a look
https://bugzilla.mozilla.org/show_bug.cgi?id=667182

Comment 11

[Nicholas Nethercote [inactive]]

I just read through bug 660577 and all its blockers again.  This bug doesn't add anything to the discussion.  I'm marking it as a dup.