image discarding making switching to tabs painfully slow

RESOLVED DUPLICATE of bug 715308

Status

()

RESOLVED DUPLICATE of bug 715308
7 years ago
7 years ago

People

(Reporter: vlad, Unassigned)

Tracking

({perf})

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

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.
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
[...]
OS: Windows 7 → All
Hardware: x86 → All

Comment 2

7 years ago
would this have started in version 5?  or 4?
Keywords: perf
Likely 4. 3.6 and before had a significantly different image discarding setup.
If we sync-decode all these images, and if we don't yield in-between sync-decodes, then that could result in this behavior.
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.
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?
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.
This should be fixed by the patch in bug 715308.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 715308
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
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Hm, that page works great for me.  What's your user-agent?
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.
> 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.
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 715308
You need to log in before you can comment on or make changes to this bug.