Hacker News new | comments | show | ask | jobs | submit login
Notes on XKCD's “Pixels” (chromakode.com)
233 points by tel on Sept 7, 2014 | hide | past | web | favorite | 56 comments

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.

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-...).

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.

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.)

This is perhaps the wrong place to discuss, but reading Noah's piece you just linked seems just a little narrow-minded... Given the struggles I see to recruit and retain contributors (who overwhelmingly $work to 17:30 and take school holidays), I'm left wondering truly how many open source projects (maybe the top 0.00001%?) can really afford to (let alone actively engage in) building their existence around these pathologies.

I don't disagree with the sentiment (hiphip-hurrah for better planning!). But in this case, I'm not sure we have sufficient information to claim malice.

Perhaps they only came up with the idea 3 days before Colbert? Perhaps Colbert asked (last minute) for a cool, new, live demo? Perhaps they were just being opportunistic, and this turned into one of those unforeseen firedrill moments? Externalities being what they are, they did a bang up job of pulling it off in time.

You're of course right that we don't know the real story, just what it looks like. However, asking an artist for an original work of art in order to promote their book on your show seems like a rather unlikely request.

Also I'm not assuming malice. However, I wouldn't congratulate them for pulling it off; this is itself encouraging the wrong thing.

In general, TV people have absolutely no idea what's involved with coding. Accordingly, they're likely to assume that it's much easier than it actually is, not realizing that their "simple" request may involve a fairly complex process to deliver.

Ironically enough, they get this principle when it comes to other people's misconceptions about television. Very few people have any idea how much time and effort goes in to film and broadcast production. Producers are constantly fielding requests from clients, executives, and others with limited technical skill who say things like "Can't you just..." or "I don't see why we don't just..." or "How about just...?".

You get the picture.

TV producers asking for original functionality (or art) is par for the course. When I did live robot demos on CNN, they asked me to code up some new functionality to display in the commercial break transition (surreal coding on the newsroom floor ensued). If Picaso were alive today... yep, on-the-fly napkin sketches.

I agree 100% with your feelings, and on top of that I find it to be a bit of humble-brag when I hear people talking about how much sleep they skipped to hit a deadline.

I have to bust ass once in a while to hit a deadline, but I always consider that a failure of my project planning. I get psyched about hitting a deadline without a single hour of overtime from any member of the team - to me that is something to brag about.

I dunno. Art plays by different rules. The opportunity to make art is often fleeting, inspiration is a harsh mistress.

It's easy to expect more out of artists. Good artists make finished works look easy, even when it could never have been. It's much harder to appreciate the insane number of constraints that come baked into every single project whose only judgment and exposure comes in that 5 second time between when you first see it and when you get bored of it and click to the next thing in your feed.

Well, except that I'm not actually trying to add a constraint. I'm trying to relax a constraint. As a member of the audience, I'm saying: hey, don't kill yourself over making this neat toy for my amusement. I don't actually want you to do that. Take all the time you need. Don't worry, I'm sure it will be great and it will show up in my feed whenever it's ready. (And maybe I should have said that in the first place.)

But of course they never asked me. Any pressure they feel comes from the imaginary audience in their heads.

How much this resembles the actual audience (which, admittedly, can be harsh, fickle and are easily distracted - guilty!) is hard to say.

Taking a broader perspective, there are of course far worse problems in the world, the sort of thing the Fair Trade advocates worry about. Demonstrated demand for consumer goods is quite a force, in aggregate. Who wants to be a millionare?

To achieve great things, two things are needed: a plan, and not quite enough time.

Leonard Bernstein

People who make their living by their art need to treat their art as a business, and set deadlines like any other business.

Actually, not every business has schedule as their top priority. That's true of most R&D efforts, and it's especially true of creative endeavors, which tend to be (in NASA parlance) "discovery driven missions."

It comes down to cheap, fast, and good. You can pick any two you like. If you're lucky, you'll get both, so you better be sure to note which matters most, because honestly, that's what's going to drive everything else. This is especially true of non-routine work, like much of art in general. Creative businesses that make a priority of hitting deadlines must either have very deep pockets, or enough latitude to ship sub-par product.

A great example of this is the Clock of the Long Now, which is being designed and built by Danny Hillis. This is a clock that is designed to run for 10,000 years. Quality is job one. Right now, they have about $43 million to work with (supplied by Jeff Bezos). When people ask when it will be ready, they say "we don't know." Pressed for a ballpark figure, the answer is simple: "No."

Who knows if it ever would have gotten done without the pressure of a deadline? I know they help me.

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

>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

[2]: https://github.com/chromakode/xkcd-pixels/blob/master/zoom.j...

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

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

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

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.)

"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.

Learning Javascript : Coding something production-worthy and non-trivial in a short timeframe :: Learning English : Writing a compelling novel

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.

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:















) 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.

It's a collaboration. Without the art and the ideas, the code would be meaningless.

Sure; I just always assumed he's writing the code himself.

Me too. What an honor to work with the man.

Interesting. I wonder why I got downvoted. I am not promoting self exploitation.

I knew he had a developer working with him for Time and such (and now I know who the dev is!), and I knew he had a server person too. The phrase "folks at xkcd" threw me off a bit though - to me it implies a whole team.

Is there an xkcd team as such? It would be good to read a bit more about them, if there's any info available.

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?

Good question.

From the article: "For this project, I chose to use vanilla JavaScript with no external dependencies or libraries. In general, we strive to keep the dependency count and build process minimal for these projects, since keeping the complexity level low gives them a better chance of aging well in the archives."

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.

As someone who helped convert #1110 (Click and drag) into one of the (subjectively) better zooming implementations (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.

Leaflet only allows discrete zoom levels as far as I know, whereas Pixels zooms continuously. I'm not sure a tile layer with an infinite number of zoom levels is possible either. At the very least, it would require extensive hacking.

I've used a mobile pinch-zoom Leaflet version that seemed to has continuous zoom.

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


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

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

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

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

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.

Disable "Enable zero-copy rasterizer" in chrome and give it another try. Its likely hitting the integrated graphics and not discrete or CPU, leading to the less than awesome FPS

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.

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

Me too - it's much more interesting to read about terrible decisions, why they were made, etc than it is to read yet another unblemished story of success. We as an industry should be better at sharing "Hey, I did this wrong because X" stories, they are both interesting and useful.

I had no slowdowns while zooming on both my seven-ish-year-old Toughbook CF-30 and my three or four-year-old desktop machine.

Chromium 38 on Linux on both.

Zooming on my x86 Chromebook was ~1fps or worse.

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.

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

Try double clicking.

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.

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, 2nd book, chapter XXIII, paragraph 2

Stephen Hawking quote (from wikipedia 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!"

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.

I'd say it was the simple assumption that the general internet audience uses IE at a much greater rate than typical XKCD visitors... And he does mention that they aren't TV watchers so didn't have any experience to draw on there.

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. ;)

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.

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.

Also found that decision strange, I would've assumed the average viewer would pull out their phone (Chrome or Safari) and check the site since nobody has a desktop or laptop anymore. I look like a time traveler from the past wandering the streets with my antiquated IBM thinkpad.

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact