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.
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.
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.
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
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.
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.
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.
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)
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 :)
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.
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?
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.
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.
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.
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.
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.
55 comments
[ 4.2 ms ] story [ 117 ms ] threadAs 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.
It doesn't seem to eat my processor too much. In Chrome with AMD processor it's sitting at about 25% CPU usage.
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.
That being said, this uses only 10-12% CPU on my quad-core machine.
Edit: Just saw your explanation. Cool - thanks!
This runs fluidly on my Chrome/Sandy Bridge/Ubuntu setup.
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.
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 :)
Uncaught ReferenceError: S is not defined
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.
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
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.
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.
Link: http://ha.ckers.org/blog/20070623/hiding-js-in-valid-images/
Example: https://github.com/christopherwoodall/ImgJs