STR: 1. Visit http://imgs.xkcd.com/turtledown/frame.html 2. Double-click, ~4 or more times, to zoom in. 3. Click and drag to try to pan around. ACTUAL RESULTS: * KINDA BAD: The 3rd and 4th zoom operation (when it starts to load the fractal-ish sub-images) are noticeably janky. * WORSE: Panning is very unresponsive. There's like a half-second delay between me clicking-and-dragging, and the graphic responding. There's less jank when zooming in Chrome, and no noticeable panning delay at all. 35.0a1 (2014-09-07) Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0

Dupe of bug 1001069?

I don't think so. http://www.xkcd.com/1416/zoom.js does have calls to getImageData and putImageData, but they don't seem to be taking up most of our time. I just did a sysprof profile of a click-and-drag (after zooming in to a point where I could see some small images), in a debug build. In that profile, drawImage() actually seems to be the most expensive single thing -- it makes up 42% of Firefox's CPU time. And essentially all of drawImage's time (40% of the total) is spent in RasterImage::GetFrame() -- specifically, its call to SyncDecode(), and (several layers down from that) MOZ_PNG_process_data. putImageData shows up, too, but is less expensive -- it's 16% of Firefox's CPU time.

Do you still see this?

There's still a little jank (and a bit more jank than Chrome) but it's miles better than it was when I filed this bug. (I just compared "mozregression --launch 2014-09-07" against current Nightly, and it's unusable in the old build & usable in current Nightly.) I'd call this WORKSFORME now.