430106 - Very bad tab-switching performance with large image in page (hang)

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Thomas Stache]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041406 Minefield/3.0pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041406 Minefield/3.0pre

When Firefox/Gecko "pages out" the image data (private bytes memory allocation in ProcessExplorer falls from ~160MB to ~68MB), switching to a tab holding the example URL, or any other larger Flickr All Sizes page takes around 10 seconds of full processor activity.

Reproducible: Always

Steps to Reproduce:
1. Load example URL in a Firefox tab.
2. Do something else in another tab in the foreground, wait til image data for the background tab is discarded.
3. Switch back to the tab with the image page -> long wait ("hang") while page is redrawn.



Another sample URL: http://www.ipernity.com/doc/23638/1794861/sizes/o
If the memory has been freed, it takes ~15 seconds to render the page (while Firefox is frozen).

Machine:
ATI X1800 graphics
AMD Athlon X2 4400+
2GB RAM

Comment 1

[Thomas Stache]

Attachment: Annotated performance graph

screenshot of ProcessExplorer showing two repetitions of switching to a tab causing the "hang" while image data is recreated/the page is rerendered.

Comment 2

[Thomas Stache]

The image sizes as two more data points:
1st 8886 x 3357px
2nd 26757 x 1900px

There is no delay switching tabs, as long as the memory has not been freed (and in Firefox 2).

Comment 3

[Martijn Wargers (dead)]

Probably a gfx:thebes bug.

Comment 4

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

Or most likely not a bug, but an unfortunate side effect.  It'll probably be WONTFIX, but Stuart can make that decision.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Is there something we can do to cut down on the decoding time here?  That seems like the way to go....

Comment 6

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

Yeah, probably -- this seems like the kind of edge case that doing threaded image decoding would be a pretty big win on multicore systems.

Comment 7

[Thomas Stache]

Out of curiosity, and not asking for a feature:
Is the current behavior of the image discarding configurable? I'm thinking about the timeout, or how much memory I'm willing to grant?

Comment 8

[Thomas Stache]

For the record, this is indeed not Windows specific: performing the above STR with the ipernity.com URL on a Macbook Pro hangs the browser UI for ≈10 seconds, before any reaction to the tab click is given to the user.

Comment 9

[Daryle Tilroe]

I'm not 100% sure if I'm experiencing this bug.  I often have a set of 10 or so tabs open with mostly images.  I was using this quite successfully with MOZ 1.7.2.  Having recently upgraded to FF 3 this mode of operation became intolerably slow.  I traced 90% of the problem to https://bugzilla.mozilla.org/show_bug.cgi?id=318378 .   However there are still two tabs that take about a second to switch to when selected.  They are just displaying 1024 x 1024 jpegs. Also if one of those tabs is active then simply redisplaying the entire FF window (or uncovering it) gives a noticeable redraw delay.  Now this does not seem to be due to the paging that this bug is being blamed on but I did not immediately find anything closer.  There seems to be something less efficient about how FF redraws or rerenders images as compared to the old 1.7.2 code.

Comment 10

[Daryle Tilroe]

Aha.  I found the problem.  It is with the scaling.  With 1.7.2 a scaled image had almost no performance hit and was better rendered somehow.  With either it appears that, if the image is scaled, every time it (or part of it) is redisplayed it has to rescale the whole thing; however FF 3 is much less efficient.  A simple test is to have two FF 3 windows open, side by side, of the same largish image, one scaled, one not.  Just drag some other arbitrary window over the top of one and the other and observe.  For comparison the same test in 1.7.2 does shows a *much less* noticeable difference.

Comment 11

[Joe Drew (not getting mail)]

This will almost certainly be solved with bug 502270.

Comment 13

[Chris Lawson (gone)]

The dupe has some good samples on this, too, in case those help anyone.

Comment 14

[Chris Lawson (gone)]

For whatever it's worth, bug 502270 may have helped *some*, but there's still a noticeable "hitch". It's not long enough to show a beachball any more, but it's definitely still there.

What's the status on re-evaluating where we are on this now?

Comment 15

[Mark Côté [:mcote]]

Attachment: large-image tab-switching peptest

Here is a peptest that reproduces this problem.  It loads the example URL into the first tab, switches to the second tab and loads mozilla.org, waits 20 seconds (the time it takes on my machine to free the memory from the first tab), then switches back to the first tab.  There is a noticeable pause, and peptest reports an unresponsive period of around 700 or 800 ms:

PEP TEST-START | test_largeImgTabSwitch.js
PEP WARNING    | test_largeImgTabSwitch.js | switch_tab | unresponsive time: 816 ms
PEP TEST-UNEXPECTED-FAIL | test_largeImgTabSwitch.js | fail threshold: 0.0 | metric: 665.856
PEP TEST-END   | test_largeImgTabSwitch.js | finished in: 37283 ms

The length of the unresponsive period appears to be related to the size of the image.  The image in the example URL is over 8000 pixels wide; with an image around 3000 pixels wide, I saw an unresponsive period of about 150 ms.  This implies an exponential relationship, though I didn't test this thoroughly.

Instructions on running peptest: https://wiki.mozilla.org/Auto-tools/Projects/peptest#Running_Tests

It would also be possible to store a large image locally and switch the URLs in the test to file:///... for inclusion in an automated suite.

Comment 16

[DB Cooper]

Should this be added as a dependency for the image-suck metabug? 

https://bugzilla.mozilla.org/show_bug.cgi?id=683284

Comment 17

[CruNcher]

hmm if the picture reload from wherever (cache,network) is asynced this shouldn't happen should it ?

Comment 18

[CruNcher]

i guess also if you disable the memory tab cache it will be more problematic ? then leaving it enabled ?

Comment 19

[CruNcher]

could someone measure browser.cache.memory.enable= false how much that impacts it ?

Comment 20

[Gregory Pappas [:gregp]]

Reporter, are you still experiencing this issue? (You can force large images in background tabs to unload by navigating to about:memory -> 'Minimize memory usage')

Comment 21

[Gregory Pappas [:gregp]]

Unable to reproduce