7 ms·

JS1k JavaScript Code Competition – Demos 2015

59 points by vmorgulis 11y ago

nodivbyzero 11y ago
This is cool: http://js1k.com/2015-hypetrain/details/2291 http://js1k.com/2015-hypetrain/details/2291
q3k 11y ago
My system (Chrome/X11/GNU/Linux) completely hung up when viewing http://js1k.com/2015-hypetrain/demo/2179 http://js1k.com/2015-hypetrain/demo/2179 ... Anyone else experience this?
- jessedhillon 11y ago
  Yes, I had the same experience. It eventually began responding, but it took ~2 minutes.
- madflame991 11y ago
  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.
- rashkov 11y ago
  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.
- pearjuice 11y ago
  It actually crashed my graphics driver.
  - victorantos 11y ago
    same here, driver crash in windows 10
- Joeri 11y ago
  Works fine in edge on lumia 950. Phones are getting ridiculously powerful.
- rogerbinns 11y ago
  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).
  - q3k 11y ago
    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...
  - rogerbinns 11y ago
    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.
- desuvader 11y ago
  Running very smoothly for me. Tested on Chrome 47, Win 10 with 970 strix card.
- steve_taylor 11y ago
  It completely froze my 2011 MacBook Air with the latest OS X and Chrome.
- m1sta_ 11y ago
  Macbook 12 running Windows 10. Killed the graphics card driver but it restarted fine.
deleted 11y ago
[deleted]
z3t4 11y ago
There are some awesome demos, but I think code size is a stupid limit, yet I can not come up with any better restriction.
- NeutronBoy 11y ago
  What do you mean stupid? It's the entire point of the competition. Do you mean that it's got no 'real-world' relevance?
  - z3t4 11y ago
    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.
kozak 11y ago
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.

59 points by vmorgulis 11y ago

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

q3k 11y ago

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

jessedhillon 11y ago
Yes, I had the same experience. It eventually began responding, but it took ~2 minutes.
madflame991 11y ago
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.
rashkov 11y ago
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.
pearjuice 11y ago
It actually crashed my graphics driver.
- victorantos 11y ago
  same here, driver crash in windows 10
Joeri 11y ago
Works fine in edge on lumia 950. Phones are getting ridiculously powerful.
rogerbinns 11y ago
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).
- q3k 11y ago
  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...
- rogerbinns 11y ago
  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.
desuvader 11y ago
Running very smoothly for me. Tested on Chrome 47, Win 10 with 970 strix card.
steve_taylor 11y ago
It completely froze my 2011 MacBook Air with the latest OS X and Chrome.
m1sta_ 11y ago
Macbook 12 running Windows 10. Killed the graphics card driver but it restarted fine.

deleted 11y ago

[deleted]

z3t4 11y ago

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

NeutronBoy 11y ago
What do you mean stupid? It's the entire point of the competition. Do you mean that it's got no 'real-world' relevance?
- z3t4 11y ago
  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.

kozak 11y ago

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.