> My plane landed in SFO a half hour before our rough goal of launching midnight EST. While my cab was hurtling me home at 80mph, the folks at xkcd were putting the final touches on the art and server code. We cobbled it all together over IRC and went live at around 1:30am EST.
We're in Daylight Saving time. EDT. Or just "ET" or "Eastern", which are good year-round. (Or "America/New_York" if you're feeling pedantic.)¹
Unless of course you just don't observe Daylight saving time, and you were actually working in EST, in which case, respect.
> As you scroll deeper, pos becomes a long array of the nested pixels you've entered, like [[305, 222], [234, 674], [133, 733], ...]
Doesn't this mean that crossing a panel boundary means we need to pop up the stack? And, if I'm on the bottom-most panel of a bottom-most panel and I cross that boundary, mean two things off the stack? And if I'm evil, and keep zooming in on that bottom of the bottom of the […] bottom of the bottom of the bottom of a pixel, and then move across that boundary:
Uncaught RangeError: Maximum call stack size exceeded zoom.js:529
TurtlesDown.render zoom.js:529
TurtlesDown.render zoom.js:586
TurtlesDown.render zoom.js:576
TurtlesDown.render zoom.js:586
TurtlesDown.render zoom.js:576
TurtlesDown.render zoom.js:586
TurtlesDown.render zoom.js:576
TurtlesDown.render zoom.js:586
TurtlesDown.render zoom.js:576
[… (it's turtles all the way down!) …]
(Some bugs to be expected given the development timescale, of course. :-) And, to be fair, when I thought about "how would you implement this?", yours was the solution I had in mind. Tough edge case here though; you note the problem with addition and carry in your post too, and I wonder if I just ran into a corner case of that.)
I did greatly enjoy this comic. Especially once I determined that it gave different panels depending on where you zoomed in.
> browsers were still too slow to draw all 360,000 individual pixel panels via Canvas
>We're in Daylight Saving time. EDT. Or just "ET" or "Eastern", which are good year-round.
Point taken. :)
>Doesn't this mean that crossing a panel boundary means we need to pop up the stack?
Aha! Yes, now that I'm looking closely, I think that is possible, since the logic that handles crossing outside of the current "pos" pixel boundary is re-entrant.
However, I note that the line numbers in your trace are alternating. This looks suspiciously like an oscillation between the "need to zoom out and find a new pos" and "need to zoom in and set pos" states. It just occurred to me that since these conditionals compare floating point positions directly, it might be possible for a precision error to cause such a loop.
This exercise has made me realize a benefit to the mess of carrying code that happens further down, when wrapping around the 4 panels that are actively being displayed. That code will in principle operate past the point where a recursive implementation will stack trace, FWIW. According to StackOverflow [1], that'll be around 25K/50K nestings in Chrome/Firefox.
>Would mipmapping help any here?
Yep! The current implementation only scales an image once per render, caching the resultant image data and reusing it for all of the other draws [2]. Images are also pre-scaled to various intervals (for example [3]), though that was to improve image scaling rather than performance. Actually, while working on the mipmapping implementation, I found evidence that the canvas putImageData call (for image buffers) is a good deal slower than drawIamge [4]. It looks like where I left things, I'm still using putImageData. Tomorrow, I'll try caching the actual canvas elements and see if that gives the predicted huge performance boost.
> My plane landed in SFO a half hour before our rough goal of launching midnight EST. While my cab was hurtling me home at 80mph, the folks at xkcd were putting the final touches on the art and server code. We cobbled it all together over IRC and went live at around 1:30am EST.
We're in Daylight Saving time. EDT. Or just "ET" or "Eastern", which are good year-round. (Or "America/New_York" if you're feeling pedantic.)¹
Unless of course you just don't observe Daylight saving time, and you were actually working in EST, in which case, respect.
> As you scroll deeper, pos becomes a long array of the nested pixels you've entered, like [[305, 222], [234, 674], [133, 733], ...]
Doesn't this mean that crossing a panel boundary means we need to pop up the stack? And, if I'm on the bottom-most panel of a bottom-most panel and I cross that boundary, mean two things off the stack? And if I'm evil, and keep zooming in on that bottom of the bottom of the […] bottom of the bottom of the bottom of a pixel, and then move across that boundary:
(Some bugs to be expected given the development timescale, of course. :-) And, to be fair, when I thought about "how would you implement this?", yours was the solution I had in mind. Tough edge case here though; you note the problem with addition and carry in your post too, and I wonder if I just ran into a corner case of that.)I did greatly enjoy this comic. Especially once I determined that it gave different panels depending on where you zoomed in.
> browsers were still too slow to draw all 360,000 individual pixel panels via Canvas
Would mipmapping help any here?
¹At least it isn't carved in stone: http://thumbs.dreamstime.com/z/clock-grand-central-station-n....