JS1k JavaScript Code Competition – Demos 2015 | Hacker News Reader

JS1k JavaScript Code Competition – Demos 2015

js1k.com

59 pointsvmorgulis18 comments

My system (Chrome/X11/GNU/Linux) completely hung up when viewing http://js1k.com/2015-hypetrain/demo/2179 ... Anyone else experience this?

Yes, I had the same experience. It eventually began responding, but it took ~2 minutes.

Managed to close it twice, but it took a while. I don't understand how a single application can render a whole (multicore) system unresponsive. Isn't the OS supposed to take control from a long-running task once in a while? I've encountered dozens of other graphical demos in JS that cause the same thing. I'm running Chrome 48 on Linux.

Works well for me on Linux Chrome 46.0.2490.86 (Official Build) (64-bit). Strangely though I've been having trouble with amazon.com locking up the tab. I've got a dedicated graphics card in this thing though, with a heap of ram, so that may be the difference.

It actually crashed my graphics driver.

same here, driver crash in windows 10

Works fine in edge on lumia 950. Phones are getting ridiculously powerful.

I did a bit more digging. Using Ubuntu 15.10 64 bit on a system with Intel HD4000 graphics. I was getting about one frame every 3 seconds and the system felt very unresponsive (eg takes a minute or two to kill the tab). But the mouse pointer moved.

Connecting in via ssh showed that the system was just fine and close to idle. It was the GPU where the issues are. I ran intel_gpu_top and what you see is that render busy is at 100% as is blitter busy (most of the time). Essentially the gpu is saturated. I do wonder if this is similar to bufferbloat, but with so much work pending for the gpu that other requests take a long time to run.

I ended up having to kill -9 chrome, and ended up with a hung system (ie even magic sysrq didn't work).

That is consistent with my theory as well. It would be awesome if someone more experienced in the Intel graphics stack would dig a bit more into what was happening...

Since another commentor mentioned it running fine on their mobile device, I decided to run it on my tablet which coincidentally also uses an Intel Atom cpu + gpu.

It chugged along at about one frame every two seconds for about 10 seconds, before an app not responding dialog appears. I reported it, and the tab was restarted. On the restart I get a bottom of Chrome message "Rats! WebGL hit a snag". It has a helpfully (not) grayed out "Learn More", Reload or Ignore. No matter what I did I couldn't get it working again, with the browser showing "WebGL not supported".

On my Nexus 5 it ran just fine - smoothly even although there is a lot of aliasing.

Running very smoothly for me. Tested on Chrome 47, Win 10 with 970 strix card.

It completely froze my 2011 MacBook Air with the latest OS X and Chrome.

Macbook 12 running Windows 10. Killed the graphics card driver but it restarted fine.

This is cool: http://js1k.com/2015-hypetrain/details/2291

1k seems like too little. If we take classic 64k .exe demos as a "gold standard", then we need to define some limit that would allow to replicate that amount of stuff in JS. Should it be 16k, 32k, 64k? Is textual JS code more compact or is it less compact than legacy binary .exe files? That's not a straightforward question to answer.

There are some awesome demos, but I think code size is a stupid limit, yet I can not come up with any better restriction.

What do you mean stupid? It's the entire point of the competition. Do you mean that it's got no 'real-world' relevance?

What would you say if your software colleges tried to write their code in as few characters as possible? <grin> It always result in "obfuscated" code.

Maybe there should be a code competition where you get points for simplicity as wells as how impressive the result is!?

In sports there are no secrets, just different philosophies.

Reply on news.ycombinator.com