Closed Bug 676270 Opened 14 years ago Closed 3 years ago

Visible lag restoring images on tab switch

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: johnath, Unassigned)

References

Details

In the last little while (a few weeks maybe?) I've been noticing quite a visible lag between switching to a tab and having the images on that tab painted. After some discussion with Joe and Jeff, it seems that this was a result of recent changes from jlebar which attempt to make some pathological image cases more responsive on tab swap. My concern is that we have made a common case worse in order to ameliorate a pathological case, if my experience is reflective of the general user (I am strange as a human being, but I don't think swapping to a tab with a flickr image is strange behaviour, and the lag is visible there). My understanding is that we have some dials to control here, that we adjusted timings well down in pursuit of greater responsiveness, but that there might be merit in pulling back from our current position. Cc'ng the parties to the discussion for comment, since we are much deeper into your depths than my own.
Did Joe and Jeff already rule out that this was caused by changing the discard timer from 120s down to 10s (bug 664290)? That seems like a more straightforward cause. Joanth, you could test by changing image.mem.min_discard_timeout_ms back to 120000.
I suspect it has more to do with bug 590260 - we're only decoding 4096 bytes at a time, and for a maximum of 5 ms.
I guess what you're suggesting is that the issue here is that images take longer to decode, now that we're decoding in smaller block sizes and yielding every 5ms as opposed to every 400ms? What I'm suggesting is that we're simply discarding images more often than we were before, and that with or without the yield time change, decoding large images takes time. What Jonath is seeing here seems very similar to bug 664290 comment 19. In my tests, the only circumstance where yielding every 5ms as opposed to every 400ms made a perceptible difference in the time to decode was when decoding large images out of the browser's cache. I didn't see a difference in speed when decoding discarded images. But my tests could have been wrong! Jonath, if you make the following pref changes: image.mem.decode_bytes_at_a_time --> 200000 image.mem.max_ms_before_yield --> 400 do you notice a difference in behavior?
...or Joe, if you can find a site site whose images decode-after-discard faster with those prefs switched, that would confirm your theory. I haven't been able to find such a site myself.
Jeff, we did a bunch of experiments on my machine - do you remember what we learned?
Hi Justin, I've found a site where the config change in comment 3 above makes a big improvement, the boston.com "The Big Picture" blog: http://www.boston.com/bigpicture/2011/12/the_year_in_pictures_part_ii.html The page has 45 fairly large (990x660) jpegs, and uses about 115 MB uncompressed-heap in about:memory when active. On this machine (4x3.4GHz, 6GB RAM) the page takes 7-8 seconds to decode images in Firefox 9.01 with default image.mem settings, if the tab has been inactive for 10+ seconds. With these about:config settings it takes only about 1 second: image.mem.decode_bytes_at_a_time --> 200000 image.mem.max_ms_before_yield --> 400 I was going to set min_discard_timeout_ms to something fairly high to avoid the annoyance, but these settings seem nearly as good while still allowing decoded images to drop from memory.
That's very interesting! FWIW, the current configuration parameters are there to minimize the amount of time the browser is unresponsive while it decodes images. With your new settings, I'd expect Firefox to be basically frozen while it decodes the images. But I'm surprised that those settings affected the total time to decode. I'll try to investigate tomorrow.
david, what operating system and version of Firefox are you running? On my Linux machine, changing those prefs doesn't have a big effect on how long the images take to re-decode.
Oh, so one problem is that you have to restart the browser in order for it to re-read these prefs. That's a bug.
Hi Justin, Thanks for investigating. I'm on win7x64, Firefox 9.0.1 (release channel on this machine). Yes, decode_bytes_at_a_time and max_ms_before_yield seem to need a restart, but min_discard_timeout_ms doesn't. I did a quick test to see if CPU throttling might have something to do with it (in case firefox only working for 5ms at the time made the cpu jump more between the high/low speed or something), but had the same result after pinning the frequency. Firefox isn't entirely frozen with the 400/200000 setting - I can switch tabs but not scroll in this tab until the images are loaded. With default settings I can scroll, but it's very laggy. I'd rather have the tab fully frozen for 1-2 seconds than almost frozen for 7-8. Something else that's weird, with default settings - the very first time the images are loaded (if I have just restarted the browser, and the tab is open in the background but not yet activated) then the images load much faster when I switch to the tab than if they had been loaded once then discarded! On this load I also see the progressive "boxy" jpeg loading (instead of fully black until the image is all done). Let me know if you'd like me to run any other test?
Per bug 715919 comment 4, the Big Picture is a particularly bad offender because it uses progressive jpegs, which libjpeg-turbo doesn't make fast, and are anyway slow to decode. Not that we shouldn't fix it...
I dont know if this ever got fixed but I am seeing this issue on win7 64 bit firefox 36.0.1 I have a powerful PC and it makes me feel like I am running on a 386 with how slow images appear on tab switching, and its not just big images but things like smilies on forums as well.
Resurrecting this after 3 years, wonder if the information in here is too stale to act on - Chris, perhaps some example pages and an explicit steps to reproduce just so that we're talking about the same thing?
Severity: normal → S3

Unable to reproduce in recent versions.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.