Show HN: My first WebGL demo, the first self-extracting PNG ever? | Hacker News Reader

Show HN: My first WebGL demo, the first self-extracting PNG ever?

demoseen.com

101 pointsdaeken55 comments

I've been working on this for a couple weeks, attempting to get it looking perfect and get it to 1kb. It's going to be going on stage at http://solskogen.no/ shortly, so I figured now is the perfect time to post.

As far as I know, this is the first ever case of a self-extracting PNG -- the file is a PNG that first is interpreted as HTML, which then unpacks the compressed code within the PNG to start the second stage. I plan to write a blog post about how I got the size down as far as it is, but feel free to ask any questions you may have, as I'd love to see this technique spread!

Edit: Requires Chrome and Firefox -- has been tested heavily on Windows and OS X, but this will eat your CPU and GPU alive.

Pretty cool hack! I'm looking forward to the blog post.

It doesn't seem to eat my processor too much. In Chrome with AMD processor it's sitting at about 25% CPU usage.

Thanks!

It isn't too be on the CPU for most people, but for some reason it's eating a massive chunk of CPU-time for some people -- seems to be only in the latest Firefox nightlies, but i'm not seeing it here, so I'm unsure of what it could be.

Just to add another token data point. I have it up full screen at 1920x1200. CPU usage is sitting between 50 and 75% of one core and GPU usage jumps back and forth between 40% for a few seconds and then 80% for a few seconds. This is using Chrome 14.0.814.0 dev-m

Do you have a quad core CPU by chance? 25% is the max that a single-threaded process would use. (Someone please correct me if this is wrong, but at least this is the behavior I've observed.)

That being said, this uses only 10-12% CPU on my quad-core machine.

Ah, I guess I should have specified. It's a Phenom 8750 (triple core.)

It depends on what you use to report CPU usage. Many monitoring tools stick with 100%/core, but some normalize it.

Good point. I believe Windows' task manager reports it the way I said, while OS X's Activity Monitor reports each core up to 100%.

In general, *nixes report 100% capacity per core, not just OS X.

If it's 1k, then it's a serious contender.

Daeken... you are, as usual, nothing short of amazing. Never fail to amaze :)

So, it the header makes it look like a PNG:

    magister.html: PNG image data, 1242 x 1, 8-bit grayscale, non-interlaced

If you look at this in an image viewer, it's as advertised: a long black bar.

So what this is is some garbage data with a PNG header, a token PNG image, and some HTML that bootstraps a javascript program whose main body looks like binary garbage. But it's not a self-extracting PNG, it's a very strange HTML document with a PNG header.

That's not to say it's not impressive, but the running demo looks nothing like the PNG data.

You were right up until saying it was garbage data. The image data is the demo code itself. This is a real PNG, even if it looks random.

Even so, I think this is more of a Polyglot than a self extracting PNG.

looks like it was designed as a firewall bypass

Apologies, but nothing happens when I view it. Running Chrome 12.0.742.122. I see the initial raw PNG splat, but get nothing but a lot of high cpu and a blank browser screen after running a couple minutes.

If that's the case, then you don't have WebGL enabled, or your GPU is being blacklisted by your browser.

I have the same issue in Chrome on OSX, and WebGL is enabled for me. I've played some of the WebGL demo games, so I doubt it's due to my GPU being blacklisted.

Hmm, unusual. Can you see http://demoseen.com/windowpane/magister.test.html ?

I cannot, although all of the demos I've tried here work: http://www.khronos.org/webgl/wiki/Demo_Repository

Only thing I can think of at this point is that you have an extension inserting something into the body before the canvas. While on Magister, drop javascript:alert(document.body.firstChild) into the address bar and see if you get the canvas -- if not, that's the problem.

The tab crashes after a while when I try that. Weird. Even with all extensions disabled, it hangs without ever finishing loading.

Old version of chrome perhaps? Works fine on my chrome on osx here. 12.0.742.122 here. (I'm technically out of date too, mostly because I haven't restarted chrome in a while)

Nope, I'm on the same version as you, although it tells me that's the latest version.

It does not work for me either - blank white screen. Same setup, Mac OS X and Chrome. I do get the canvas when pasting that snippet, though.

Same situation as the rest of this thread - I just get cpu usage and a white screen, in Chrome stable/beta/dev. OSX on a MBP, only thing I can think that might be shared with others having problems is my GPU: GeForce 8600M GT. I haven't heard of problems with this card before, but OSX + GPU ≠ consistent results, at times.

Though interestingly, the behavior in all three Chromes is wildly different: Dev runs 60% CPU use in the rendering process, Beta sometimes uses nothing, sometimes 60%, and Stable uses the same 60% + 120% on "google chrome helper". The alert test works (shows a canvas element) in both Dev and Beta, Stable shows me a "page unresponsive" after a couple seconds and never alerts anything.

Other GL tests work just fine in all 3. I'll be happy to test other things if you can come up with them :)

Nope. You have a js error somewhere:

Uncaught ReferenceError: S is not defined

That's not a JS error. 'S' is a function defined in WebGL, which gets pulled out and names are passed through a regex that filters out certain characters. So it's not getting a WebGL context, and thus that function never ends up being pulled into the global namespace.

For whatever it's worth, I'm on the same build of Chrome (12.0.742.122) on OSX 10.6.8 and the demo is working fine for me.

To see if WebGL is enabled you can type this in the address bar

  about:gpu

Also helpful

  about:flags

For what its worth, it seems to be running now without any changes on my part.

Wow, that's strange. No changes here either. Wonder what's going on.

Very neat. I'm happy to see that the demo scene magic still exists. I thought the days of seeing an animated ray traced scene from a 256 byte EXE were over.

This runs fluidly on my Chrome/Sandy Bridge/Ubuntu setup.

I like the demo on the "front page", as well: http://demoseen.com/

It crashes though, when you run it with this hash: 0FP$9jj!i1!!!DPD!t!!!!!~ It spun up 5M threads before it died, which was admittedly fun to watch.

There are a dozen or so different demos and experiments sitting on the site now, but no way to get to any of it, so the front page is soon to be a demo in itself, with the others nested inside it. A nice little interactive portfolio. But I'm glad you dig the langton hack

Hey, congrats on finally getting it out there! Saw how much work you poured into it and glad it's finally done. Also, mind-bending implementation.

I can't get this to work; low end laptop with low end gpu. But is it anything like what Rsnake posted on ha.ckers.org?

Link: http://ha.ckers.org/blog/20070623/hiding-js-in-valid-images/

Example: https://github.com/christopherwoodall/ImgJs

The bootstrap code (which unpacks the second stage, compressed in the PNG image data) does indeed work this way. The key difference is that in addition to the code at the top level of the image, there's the second stage inside.

Very cool! I'd love to read how the PNG hack works.

To see if your browser supports webgl, go to http://webglreport.sourceforge.net/

On a pokey mac mini, I get a few frames per second and about 5-15% CPU use in Firefox and chrome

Heh. Screen went black for a while, after which: "Display driver nvlddmkm stopped responding and has successfully recovered."

Using an old NVIDIA GeForce 6200 with driver 8.17.12.7533 on a 32-bit Windows Vista SP2, browser was Google Chrome 12.0.742.122.

It's fairly GPU intensive, and if Windows Vista/7 don't get a response from the GPU after a short period of time, it'll restart the drivers. Happens every once in a while even on newer GPUs, unfortunately.

Ah. So your interpretation is not that the driver actually crashed, but that it simply was overwhelmed by the workload, and didn't respond properly within the timeout limit as set by the OS?

Windows watchdog kills tasks running on a GPU after ~5 seconds (using CUDA) same might apply here

Daeken, you are a graphics/web wizard of the highest order. Congratulations :)

Aside: anyone know why Chrome doesn't release the memory after the page is exited? Looking at Chrome's stats for nerds (about:memory) I still see 57k allocated to GPU Process.

This is very cool, but when running it on Chrome 13 beta it was extremely choppy and basically locked up my PC. It took 2 minutes to move my mouse to the "close tab" button.

Can you give us a few details of what you did? This makes my i7 cry.

Edit: Just saw your explanation. Cool - thanks!

Right-click and choose "view image" hangs firefox on a mac osx sl.

(Repeated) kernel panic on Macbook Air/Chrome I'm afraid.

Can you post OS and browser versions along with the hardware revision? That sounds bad.

Same for me -- Chrome 12.0.742.122, MBA 2.13 GHz 13" latest, 4GB ram

weren't you recently searching for exploitable webgl driver bugs?

Indeed I am. In the development of this demo (and the framework which built it), I've found more bugs than while actually attempting to attack WebGL; I don't know whether to be happy or sad about this.

Sorry for the late reply. Here are my details:

Mac OS X 10.6.8 all updated / Google Chrome 12.0.742.122 / MacBookAir3,2 / 2.13 GHz / 4GB RAM

Would be interesting to know if you have, indeed, found an exploitable driver bugs.

Extraordinary.

Reply on news.ycombinator.com