671641 - image discarding making switching to tabs painfully slow

Status: RESOLVED DUPLICATE of bug 715308

(Core :: Graphics: ImageLib, defect)

Description

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

I often end up in this situation where image discarding/redecoding seems to make switching to some tabs painful.  In this particular case, if I leave firefox alone for 30s or so (I guess just > the discard timeout), switching back to my Facebook tab takes at least 5s.  An xperf profile shows:

Process, Module, Function, Weight, % Weight, Count, TimeStamp
, xul.dll, , 3206.471396, 3.55, 3209, 
, , ycc_rgb_convert, 796.398301, 0.88, 797, 
, , qcms_transform_data_rgb_out_lut_sse2, 580.554743, 0.64, 581, 
, , jpeg_idct_islow, 541.682344, 0.60, 542, 
, , decode_mcu, 363.349895, 0.40, 364, 
, , h2v2_fancy_upsample, 256.881324, 0.28, 257, 
, , mozilla::imagelib::nsJPEGDecoder::OutputScanlines, 89.956788, 0.10, 90, 
, , decompress_onepass, 39.957372, 0.04, 40, 
, , pixman_fill_sse2, 19.000076, 0.02, 19, 
, , RuleHash::EnumerateAllRules, 15.002550, 0.02, 15, 
, , sse2_composite_src_x888_8888, 14.000264, 0.02, 14, 
, , SearchTable, 13.995801, 0.02, 14, 
, , nsStyleContext::GetStyleDisplay, 13.992229, 0.02, 14, 
, , nsIFrame::InvalidateInternal, 9.975944, 0.01, 10, 
, , XPCConvert::NativeInterface2JSObject, 9.001799, 0.01, 9, 
, , nsIFrame::BuildDisplayListForChild, 8.996885, 0.01, 9, 
, , MOZ_Z_inflate, 7.990136, 0.01, 8, 
, , XPC_WN_GetterSetter, 7.002590, 0.01, 7, 
, , read_tag_curveType, 6.999017, 0.01, 7, 
, , sep_upsample, 5.998967, 0.01, 6, 
, , jpeg_huff_decode, 5.998966, 0.01, 6, 

so almost all in image decode + cms.  But at least according to page info, all the images (especially all the jpgs) are tiny... most are smaller than 50x50.  Only one or two are 400x400 or so, and they're pngs.  There aren't even all that many images to begin with, unless there are some hidden images somewhere that we're still redecoding.  My build is a nightly from http://hg.mozilla.org/mozilla-central/rev/e898a773a4fb -- 2011-07-11.

Comment 1

[Tim Taubert [:ttaubert] (inactive)]

Confirming with current nightly (2011-07-29) on Mac and Linux. Opening an imgur.com tab and scrolling down several pages results in _very_ slow (5+ secs) tab switching (when selecting the imgur tab).

Shark profile:

- 30.7%, decode_mcu, XUL
- 12.8%, ycc_rgb_convert_argb, XUL
  6.0%, jpeg_fill_bit_buffer, XUL
  4.2%, qcms_transform_data_rgb_out_lut_sse2, XUL
- 4.1%, jsimd_idct_islow_sse2.column_end, XUL
- 3.7%, jsimd_idct_islow_sse2.columnDCT, XUL
  3.7%, js::GCMarker::drainMarkStack(), XUL
- 2.6%, __bzero, libSystem.B.dylib
- 1.8%, decompress_onepass, XUL
  1.1%, mozilla::imagelib::nsJPEGDecoder::OutputScanlines(int*), XUL
- 0.9%, bcopy, mach_kernel
- 0.8%, _ZN2js2gcL9ScanShapeEPNS_8GCMarkerEPKNS_5ShapeE, XUL
- 0.7%, jsimd_ycc_rgb_convert_sse2.columnloop, XUL
- 0.7%, PL_DHashTableOperate, XUL
- 0.7%, jsimd_idct_islow_sse2, XUL
  0.7%, jpeg_make_d_derived_tbl, XUL
- 0.5%, resample_byte_h_3cpp_vector, CoreGraphics
- 0.5%, ml_set_interrupts_enabled, mach_kernel
[...]

Comment 2

[Wayne Mery (:wsmwk)]

would this have started in version 5?  or 4?

Comment 3

[Joe Drew (not getting mail)]

Likely 4. 3.6 and before had a significantly different image discarding setup.

Comment 4

[Justin Lebar (not reading bugmail)]

If we sync-decode all these images, and if we don't yield in-between sync-decodes, then that could result in this behavior.

Comment 5

[Joe Drew (not getting mail)]

Right now we have no overall tracking of sync decode time, so if we've got a pile of events that will result in sync decodes all queued up, that can result in huge delays.

One way around this would be to add tracking of overall sync decode time; if it's over a threshold, don't sync decode any more, instead adding to a queue of images to be sync decoded by another event posted to the event queue.

Comment 6

[Dietrich Ayala (:dietrich)]

I'm super tired of switching to a tab and waiting a couple of seconds for an image to re-appear. It's extremely obvious when you've opened a bunch of Flickr pages in tabs and are slowly making your way through them. Is the behaviour a manifestation of this bug? Or should I file a new one?

Comment 7

[Justin Lebar (not reading bugmail)]

Two similar but different behaviors are:

 * You click to switch to a tab.  Firefox is responsive and immediately shows the page on that tab, but images on that tab don't show up immediately.
 * You click to switch to a tab.  Firefox is unresponsive.  The page likely doesn't show up at all immediately.

This bug is nominally about the second behavior.  The first behavior was made more prevalent by bug 664290; the fix is likely bug 689411.

Comment 8

[Joe Drew (not getting mail)]

This should be fixed by the patch in bug 715308.

Comment 9

[Robert Lickenbrock [:rclick]]

I can still reproduce this, so reopening.

4walled [1] shows this quite clearly. The page contains wallpaper thumbnails and more are added when you reach the bottom of the page. If you scroll the page for a while until there are tons of images, switch to a different tab and wait ~20 seconds for discarding to happen, then switch back, the browser becomes completely unresponsive for several seconds.

[1] http://4walled.org/search.php?tags=&board=&width_aspect=&searchstyle=larger&sfw=0&search=random

Comment 10

[Justin Lebar (not reading bugmail)]

Hm, that page works great for me.  What's your user-agent?

Comment 11

[Robert Lickenbrock [:rclick]]

Mozilla/5.0 (Windows NT 6.1; rv:12.0a1) Gecko/20120131 Firefox/12.0a1

Yesterday's Nightly on Windows 7 32-bit, basically. The hardware I'm using is a single core Pentium 4 2.4GHz with 1.25GB ram.

I am scrolling for a long time though. The tab I have open right now has around 2,000 images and switching to it after the images have discarded takes ~8 seconds.

However if I set image.mem.max_bytes_for_sync_decode to 0, the switch is nice and snappy. So this seems to have something to do with the fact that we sync decode small images. I haven't dug deeper than that yet.

Comment 12

[Justin Lebar (not reading bugmail)]

> However if I set image.mem.max_bytes_for_sync_decode to 0, the switch is nice and snappy

Sounds like this is a separate issue, then (let's just ignore the extremely general summary of this bug).  Can you please file a new bug?  We've been talking about reducing the max_bytes_for_sync_decode number for a while now.