1064105 - Panning (and zooming) the canvas is not responsive, at XKCD "turtles all the way down" book promo page

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Daniel Holbert [:dholbert]]

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

Comment 1

[Jet Villegas (inactive)]

Dupe of bug 1001069?

Comment 2

[Daniel Holbert [:dholbert]]

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.

Comment 3

[Milan Sreckovic [:milan] (needinfo for best results)]

Do you still see this?

Comment 4

[Daniel Holbert [:dholbert]]

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.