
Notes on XKCD's “Pixels” - tel
http://chromakode.com/post/notes-on-xkcd-pixels
======
skybrian
I'll probably get downvoted for this, but I'm ashamed of Randal Monroe for
asking for such a crazy deadline and Max for agreeing to it.

This is an art project. Randal can set his own deadlines. There is no reason
to ask someone to work crazy sleep-deprived hours for it, even if they
volunteer. He's doing the same thing a bad boss would do, with less
justification than most.

Writing it up afterwords sets a bad example for other impressionable young
hackers who look up to these guys and will set themselves up for being
exploited when they go to work because they think it's expected of them.

I couldn't finish the article. I'm sure there are good hacks in it. But we
have to stop promoting bad behavior. If we can't do this ourselves for art,
what about when there's real pressure?

Update: to clarify, there's nothing unusual about this and there far worse
examples all the time. It's just a bit striking since Randal's image is of a
somewhat otherworldly idealist.

Backpedal #2: to avoid being overly dramatic, let me clarify that being
ashamed of someone else's behavior implies that you feel some responsibility
for their behavior, which doesn't make sense in this case. Also, not finishing
an article is, to be honest, not all that unusual.

~~~
chromakode
Thanks for making this point. I wholeheartedly agree.

I didn't anticipate this response. You're absolutely right about taking
responsibility for the example we set of project management. I personally hate
pulling all-nighters, and did not intend to legitimize the unhealthy "larval
stage" hacker culture archetype (re: [http://modelviewculture.com/pieces/the-
open-source-identity-...](http://modelviewculture.com/pieces/the-open-source-
identity-crisis)).

This was a project with crazy bounds that we all consented to sprint towards.
We are a team that has worked on many projects together across years, and are
wholly comfortable with each others' constraints and limits.

It's usually the case for our projects that inspiration arrives at the most
inconvenient time. For this one in particular, the idea came up 3 days before
launch. We had several discussions during those days where we could have
pulled the plug on this due to scheduling concerns. Each of us decided to push
forward because we wanted it to exist.

~~~
skybrian
Thanks for your response!

It seems like the basic idea could be used for anything. There's nothing about
zooming that makes it particularly appropriate for a book launch; a simple
comic would do to mark the occasion and Pixels could have launched later. So
the use of this idea for this project is a choice and the deadline is entirely
self-imposed.

(Also I do enjoy the occasional hackathon, though I won't stay up late for it.
I'll stay up late for entirely different and probably just as bad reasons.)

------
deathanatos
This is a nit, but it always bothers me:

> 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

Would mipmapping help any here?

¹At least it isn't carved in stone: [http://thumbs.dreamstime.com/z/clock-
grand-central-station-n...](http://thumbs.dreamstime.com/z/clock-grand-
central-station-new-york-city-25254083.jpg).

~~~
chromakode
>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.

[1]: [http://stackoverflow.com/a/7828803](http://stackoverflow.com/a/7828803)

[2]: [https://github.com/chromakode/xkcd-
pixels/blob/master/zoom.j...](https://github.com/chromakode/xkcd-
pixels/blob/master/zoom.js#L516)

[3]: [http://imgs.xkcd.com/turtledown/turtles-
tiled.png](http://imgs.xkcd.com/turtledown/turtles-tiled.png)

[4]: [http://jsperf.com/canvas-drawimage-vs-
putimagedata/3](http://jsperf.com/canvas-drawimage-vs-putimagedata/3)

------
TeMPOraL
Stupid question: so it's not Randall Munroe who's making XKCDs such as Pixels
of Time?

~~~
ixtli
My suppositions was always that he had help with frontend code. He's not a
professional programmer; he's a rocket scientist. Also, a _lot_ of primetime
frontend web engineering requires a very specific and deep knowledge of
javascript and compatibility issues. (N.b.: by primetime I mean when your
application is going to be viewed live by a bunch of laymen watching the
colbert report, or etc.)

~~~
archgoon
"He's not a professional programmer; he's a rocket scientist"

Um... he interned at NASA and worked for them for six months after graduating
as an independent roboticist contractor. He's been working on xkcd
professionally, full time, for 8 years since then.

Plenty of time to learn javascript.

~~~
dkokelley
I'm sure Monroe had plenty of time to do many things. Perhaps javascript is
less interesting to him than formulating answers to what-if submissions.
There's nothing wrong with asking experts to assist in their area of
expertise.

~~~
archgoon
Of course there's nothing wrong. My only point is quite the opposite.

The post I was responding to suggested "Since he is a rocket scientist, it is
unlikely that he would be able to code the frontend, and would require help",
which is absurd. Given Mr. Munroes obvious interest in programming and
computers, (see comics:

[https://xkcd.com/1180/](https://xkcd.com/1180/)

[https://xkcd.com/1172/](https://xkcd.com/1172/)

[https://xkcd.com/1168/](https://xkcd.com/1168/)

[http://xkcd.com/1137/](http://xkcd.com/1137/)

[http://xkcd.com/1068/](http://xkcd.com/1068/)

[https://xkcd.com/1024/](https://xkcd.com/1024/)

[https://xkcd.com/979/](https://xkcd.com/979/)

[https://xkcd.com/963/](https://xkcd.com/963/)

[https://xkcd.com/806/](https://xkcd.com/806/)

[https://xkcd.com/619/](https://xkcd.com/619/)

[http://xkcd.com/378/](http://xkcd.com/378/)

[http://xkcd.com/303/](http://xkcd.com/303/)

[https://xkcd.com/269/](https://xkcd.com/269/)

[https://airbrake.io/blog/internet/best-programming-xkcd-
comi...](https://airbrake.io/blog/internet/best-programming-xkcd-comics)

) it was entirely reasonable to believe that he had picked up enough
experience to code the javascript frontends.

There is simply no reason to pigeon hole the man as a "Rocket Scientist",
especially given the fact he was a roboticist previously (which, shockingly
enough, tends to involve programming). He has shown a wide variety of
interests, and if he demonstrated an ability to code frontend javascript, I
would not be surprised.

------
PanMan
Not to discount the work or end result that went in to this, but when I saw
Pixels I assumed it used a 'standard' library, e.g. Leaflet, used for many
maps (which have similar zoom) and tiles. I'm wondering why you wrote
something from scratch?

~~~
chromakode
The initial idea was to use a tileserver-based approach like leaflet. Writing
a custom renderer allowed us to have unique views per client infinitely deep
that zoomed smoothly, rather than at fixed intervals. Another benefit is
avoiding the on-disk size and generation CPU time of building tiles, as well
as the bandwidth costs of serving a bunch of redundant views of the same image
data.

~~~
ygra
As someone who helped convert #1110 (Click and drag) into one of the
(subjectively) better zooming implementations
([http://dump.ventero.de/xkcd1110/](http://dump.ventero.de/xkcd1110/)), I
immediately wondered whether Pixels would benefit from Seadragon as well. Then
I noticed that it's infinite and I wasn't quite sure anymore whether a DZI
could do that properly. Perhaps by generating a sparse DZI on the fly in the
browser. But that way probably lies madness, too. Also anti-aliasing would
have to be turned off beyond 100 % zoom of individual images, which I'm not
sure is trivial to hack in there.

Still, I think from a UX perspective the slightly springy behaviour of
Seadragon is much nicer than the algorithmic rigidity of things like Leaflet
or Google Maps.

------
justifier
jason nelson (i) had me splitting sides when i first saw his infinitely
zoomable image sydney's siberia :

[http://www.secrettechnology.com/sydney/](http://www.secrettechnology.com/sydney/)

looking through wayback archives it seems siberia was posted around july of
2011

it is a brilliant idea, very ripe for self discovery, and hopefully randall
and chomakode came to it in their own way because when i saw the comic i
immediately went into the webs looking for a shout out to jason nelson..

i was waiting for this inevitable post and link on HN for a platform to expose
more people to the weird and wonderful art of jason nelson (ii)

..

i was introduced to nelson through his gamegamegame(iii), a wild platformer
that could best be described how futurama describes beck: 'transcends genres
even as he re-invents them';

(i)
[http://en.wikipedia.org/wiki/Jason_Nelson](http://en.wikipedia.org/wiki/Jason_Nelson)

(ii) [http://www.secrettechnology.com/](http://www.secrettechnology.com/)
(warning autostarts noise)

(iii)
[http://www.secrettechnology.com/gamegame/gamegame.html](http://www.secrettechnology.com/gamegame/gamegame.html)

~~~
MaysonL
OMG – that gamegame triggered weird after-images reminiscent of visual
migraines: the white background of my monitor is pulsating in many colours.

------
baddox
I enjoy hearing people comment on their own "terrible" design decisions,
though they never seem as bad as some of my own. :)

Regarding performance, did anyone else have absolutely awful frame rates when
zooming? On my beefy Macbook Pro in Chrome it would drop to two or three
frames per second.

Edit: and on my Windows PC in Chrome, which was fairly beefy three years ago,
it's more like a frame every few seconds.

~~~
chromakode
If the code detects that rendering a frame takes a while, it increases the
threshold in which sub-panels are drawn. Hopefully it should speed up after
those first couple frames.

~~~
baddox
I must have gone at least 20 levels deep and it never noticeably improves.

------
frooxie
I just realized it's made for use with a scroll wheel. I use a Wacom pen, not
a mouse, so the instructions were confusing to me.

~~~
egypturnash
I feel your pain, fellow Wacom-instead-of-mouse person.

------
wz1000
The script that renders the comic seems to consume an ungodly amount of ram.
It ate up close to six GB's of ram on Firefox running on Arch Linux, and
forced my X server onto swap. On Chromium, the comic is navigable, but the
page still consumed close to one GB of memory.

------
gioi
It makes me remember John Locke's _An Essay Concerning Humane Understanding_
[0]

> The Indian before mentioned [...], saying that the world was supported by a
> great elephant, was asked what the elephant rested on; to which his answer
> was—a great tortoise: but being again pressed to know what gave support to
> the broad-backed tortoise, replied—SOMETHING, HE KNEW NOT WHAT

\-- [0]
[http://www.gutenberg.org/cache/epub/10615/pg10615.txt](http://www.gutenberg.org/cache/epub/10615/pg10615.txt),
2nd book, chapter XXIII, paragraph 2

~~~
sp332
Stephen Hawking quote (from wikipedia
[http://en.wikipedia.org/wiki/Turtles_all_the_way_down](http://en.wikipedia.org/wiki/Turtles_all_the_way_down))

A well-known scientist (some say it was Bertrand Russell) once gave a public
lecture on astronomy. He described how the earth orbits around the sun and how
the sun, in turn, orbits around the center of a vast collection of stars
called our galaxy. At the end of the lecture, a little old lady at the back of
the room got up and said: "What you have told us is rubbish. The world is
really a flat plate supported on the back of a giant tortoise." The scientist
gave a superior smile before replying, "What is the tortoise standing on?"
"You're very clever, young man, very clever," said the old lady. "But it's
turtles all the way down!"

------
davezuko
Very interesting. I love to see how people deal with such tight deadlines,
especially when they hit that eventual point mentioned in the article where
things just sort of work out of sheer effort and it's too late to change their
approach.

I am curious, however, about this comment: "We anticipated a higher proportion
of the Colbert Report referrals would be using IE." What was the rationale
behind this? Maybe I'm just wrong in my assumptions about the Colbert
audience, but I'd definitely have expected a much more mobile-heavy (and non-
IE) group.

~~~
chromakode
We definitely should have known better. Admittedly none of us had watched
television in front of a TV for quite some time. I think this was a case of
focusing too sharply on what was broken vs. what our audience would consist
of. xkcd's audience typically slants away from IE, so we anticipated the TV
influx would be more average. That being said, the record high 6% IE numbers
achieved didn't quite justify the time spent. ;)

~~~
dwd
The big problem with browser stats is that they are averaged over a day or
month. Maybe not an issue with a global audience, but for a local audience you
find desktop use is mostly limited to between 8-6 while people are at work.
Mobile spikes during the morning and late afternoon commutes and tapers off
into evening. Tablets have a smaller morning/afternoon spike and gradually
pick up in the evening. This is fairly consistent over a number of .com.au
sites I have analysed mobile traffic for.

So, at the time you're running your evening TV advertisement or PR spot it's
80% mobile, not the 25% the stats tell you.

~~~
dangayle
He mentioned in the article that it was live data (like Chartbeat or GA Real-
Time) they were looking at, not aggregate (like regular GA).

Nevertheless, you're correct, and watching the peaks and valleys and plateaus
between the different platforms is incredibly interesting to analyze.

------
anon1110
It seems pretty broken to me. When I zoom in far enough, it fades from the
original zoomed pixels to a new image as per the design. But, unlike the
design illustration, and unlike what one would expect from an infinite zoomer,
the new image that fades in has no correspondence to the original. It should
be that white pixels in the original correspond to mostly white images in next
level image, and black pixels in the original should correspond to mostly
black images in the next level image. But there is no correspondence.

