Right now we get pretty severe image "pop in" while scrolling on dual core machines. To see it for yourself, wait for this page to load and then hold down the spacebar: http://www.neogaf.com/forum/showthread.php?t=996617 You'll see that we rapidly scroll past the image decoder's ability to keep up. On quad core machines there's no pop in on this page. Which makes sense - on a quad core machine we create 3 image decoding threads, but on a dual core machine we only create 1. So a quad core machine can potentially bring three times as much computational power to bear on image decoding. We should improve our perceived image decoding performance in this situation. This will help a large segment of our users who have dual core CPUs, and it's likely that whatever optimizations we add can help everyone.

I think there are two obvious things to try here: (1) Decode images in LIFO rather than FIFO order. That should help us keep the decoder working near the viewport when scrolling. (2) On dual core machines, start two image decoding threads instead of one, but reduce the priority of the second thread, so it doesn't overwhelm the main thread when the main thread is busy. This could potentially double the speed at which we could decode images on dual core machines in some cases. A naive implementation would have the disadvantage that the lower-priority thread might sometimes grab work even if the higher-priority thread is available; we should be sure to avoid that pitfall.

Now that bug 1160421 has landed, it's time to write scheduler patches to implement the tweaks in comment 1.

Closing this metabug since the blockers are now all fixed.

Release Note Request (optional, but appreciated) [Why is this notable]: We now have noticeably better perceived image decoding performance on all devices, but especially dual core devices, where we've potentially doubled our image decoding throughput. This is most visible when scrolling. [Suggested wording]: Images are now decoded in a smarter order and up to twice as fast on some devices, reducing pop-in while scrolling. [Links (documentation, blog post, etc)]: I have nothing other than this bug.

Noted as: Improved image decoding with performance up to twice as fast on some devices especially while scrolling

Updating relnote-firefox to 41+ based on comment 5.

(In reply to Seth Fowler [:seth] [:s2h] from comment #4) > Release Note Request (optional, but appreciated) > [Why is this notable]: We now have noticeably better perceived image > decoding performance on all devices, but especially dual core devices, where > we've potentially doubled our image decoding throughput. This is most > visible when scrolling. > [Suggested wording]: Images are now decoded in a smarter order and up to > twice as fast on some devices, reducing pop-in while scrolling. > [Links (documentation, blog post, etc)]: I have nothing other than this bug. Hey Seth, this seems like a notable win for Firefox so we'd like to call this out on a blog post for our 41 release highlighting performance improvements. Can you share whether we do this better than competing browsers? My understanding is that users will have a much better experience while browsing pages heavy with images. Is there anything else regarding this that would be important to call out/know? Positive or negative.

(In reply to Fabio Rios [:frios] from comment #7) > Hey Seth, this seems like a notable win for Firefox so we'd like to call > this out on a blog post for our 41 release highlighting performance > improvements. Can you share whether we do this better than competing > browsers? We do things very differently than others browsers; it's hard to compare. In general, as of the last time I investigated, WebKit/Blink decode images synchronously when painting. We (to a first approximation) never do that, and instead decode all images asynchronously. That means that we can potentially have better painting performance, which translates into better scrolling performance. The flip side is that we have to be smart about predicting when an image will be needed soon and starting the decoding process early, or else we get "pop in", as discussed in this bug. > My understanding is that users will have a much better experience while > browsing pages heavy with images. Is there anything else regarding this that > would be important to call out/know? Positive or negative. From my perspective the important takeaway is that we're taking better advantage of multiple cores for image decoding. This is especially true on dual core devices, which includes most Android mobile devices, since we can now use both cores for image decoding on those devices, while before we could only use one. That translates, as you say, into a better experience while browsing pages with many images.