3 ms·

I always wonder when I see these demos: what is it like in a real world workload? I remember some years ago everyone was going nuts over how WebGL was able to

I always wonder when I see these demos: what is it like in a real world workload? I remember some years ago everyone was going nuts over how WebGL was able to render a detailed model in the browser, native games are dead! Except it was a single non-animated 3D model, in a simple or non-existent background. real games had many animated models, in complex environments, with complex interaction, physics, AI, audio and gameplay logic. Ever since that comparison, I think, yeah, those demos look cool and indeed silky smooth, but most are a single simple thing. Real workloads tend to be much more complex: how does it fare with those? (Of course if the vast majority of the processing time is in the GPU, then it really doesn’t matter what language, fast or slow, you use to control or feed it.)

untog 6y ago
One recent innovation that (IMO) hasn’t got much attention is OffscreenCanvas. Even with WebGL, JS has been sorely limited by the fact that it’s single threaded. OffscreenCanvas lets you pass a drawing context off to a separate thread, or multiple contexts to multiple threads even. There’s a whole lot of potential there that I haven’t seen tapped yet (but I’ll admit I’m not very clued into the kind of scenes you’d see making the most of this). As ever, browser support matters. Chrome and Firefox: yes. Safari? No. https://bugs.webkit.org/show_bug.cgi?id=183720 https://bugs.webkit.org/show_bug.cgi?id=183720
- rikroots 6y ago
  I'm excited by the prospect of OffscreenCanvas, and yet at the same time I'm not convinced that it's going to be massively useful for my canvas library[1]. The one area where it could have a big impact (I think) would be to run the OC in a web worker alongside the bulk of the library's code, leaving the main thread to deal with final canvas display, user interactions, etc. But to implement that I'd need to recode the entire library from scratch. At the moment I generate additional canvas elements in the code (in a pool, for reuse) and use them without adding them to the DOM. I'm happy with the resulting frame rates, and the flexibility the system gives me for creating responsive, accessible canvas elements in the web page. This is all done using a simple 2d context (even the bendy images code[2] is 2d, rendered in the main thread). I've avoided WebGL and the whole GPU acceleration thing because shaders scare me more than quaternions! [1] - Scrawl-canvas - https://scrawl.rikweb.org.uk/ https://scrawl.rikweb.org.uk/ [2] - Bendy images interactive demo - https://scrawl.rikweb.org.uk/demo/canvas-024.html https://scrawl.rikweb.org.uk/demo/canvas-024.html
Jasper_ 6y ago
I've been running https://noclip.website https://noclip.website for a few years now, which, while not a "real-world" workload, clearly approaches the amount of data that a game has to render. Check out e.g. https://noclip.website/#smg/AstroGalaxy https://noclip.website/#smg/AstroGalaxy which approaches the number of draw calls I'd expect a modern game to render with. There are a lot of upsides to running it through the web platform (the big one is that I can give people a link and they can click it, rather than convince them to run an app, but there are others, too). There are downsides: performance is heavily variable. A new Chrome can launch and my performance can be 5x worse than before, which is why I now always test in Canary to make sure I'm ahead of all issues. In Chrome, the WebGL layer is pretty solid, but I still find plenty of bugs and performance issues (e.g. looking at a profile unearthed this very simple issue causing browser resizing to be way slower than it needed to be https://bugs.chromium.org/p/chromium/issues/detail?id=1103473 https://bugs.chromium.org/p/chromium/issues/detail?id=110347... ). Firefox is quite a bit slower and has a bit more draw call overhead than Chrome (I'm guessing they run validation on the main thread rather than an IPC process, causing JS to block) Most of the performance problems I encounter are actually JS-related, it's super easy to be knocked off of a fast path by complete accident, and there aren't good tools to know what I'm doing wrong. Math and ALU is plenty fast -- doing matrix multiplication on the CPU has never been a bottleneck, and you actually want that more on the CPU so that the GPU doesn't have to run a matrix mul for every pixel. Uniform data computation belongs on the CPU. My big thing that I fight is the garbage collector, and you can see the awkward "manual register allocation" code style I sometimes resort to to make sure my allocations per-frame are super minimal, especially in fast math code. It doesn't look like traditional ergonomic JS code: https://github.com/magcius/noclip.website/blob/master/src/SuperMarioGalaxy/Shadow.ts#L249-L252 https://github.com/magcius/noclip.website/blob/master/src/Su... I could go on if wanted but this comment is already getting pretty long.
- jfkebwjsbx 6y ago
  That sounds like a development nightmare like the one of the IE6 era, and even worse for supporting customers. Basically you are saying code performance is nondeterministic across your user base and across time too? I am glad WebGL is a thing for pages that need some 3D widgets where performance is not a big deal. But for general software or games? I will keep my native software.

untog 6y ago

One recent innovation that (IMO) hasn’t got much attention is OffscreenCanvas. Even with WebGL, JS has been sorely limited by the fact that it’s single threaded. OffscreenCanvas lets you pass a drawing context off to a separate thread, or multiple contexts to multiple threads even. There’s a whole lot of potential there that I haven’t seen tapped yet (but I’ll admit I’m not very clued into the kind of scenes you’d see making the most of this). As ever, browser support matters. Chrome and Firefox: yes. Safari? No. https://bugs.webkit.org/show_bug.cgi?id=183720 https://bugs.webkit.org/show_bug.cgi?id=183720

rikroots 6y ago
I'm excited by the prospect of OffscreenCanvas, and yet at the same time I'm not convinced that it's going to be massively useful for my canvas library[1]. The one area where it could have a big impact (I think) would be to run the OC in a web worker alongside the bulk of the library's code, leaving the main thread to deal with final canvas display, user interactions, etc. But to implement that I'd need to recode the entire library from scratch. At the moment I generate additional canvas elements in the code (in a pool, for reuse) and use them without adding them to the DOM. I'm happy with the resulting frame rates, and the flexibility the system gives me for creating responsive, accessible canvas elements in the web page. This is all done using a simple 2d context (even the bendy images code[2] is 2d, rendered in the main thread). I've avoided WebGL and the whole GPU acceleration thing because shaders scare me more than quaternions! [1] - Scrawl-canvas - https://scrawl.rikweb.org.uk/ https://scrawl.rikweb.org.uk/ [2] - Bendy images interactive demo - https://scrawl.rikweb.org.uk/demo/canvas-024.html https://scrawl.rikweb.org.uk/demo/canvas-024.html

Jasper_ 6y ago

I've been running https://noclip.website https://noclip.website for a few years now, which, while not a "real-world" workload, clearly approaches the amount of data that a game has to render. Check out e.g. https://noclip.website/#smg/AstroGalaxy https://noclip.website/#smg/AstroGalaxy which approaches the number of draw calls I'd expect a modern game to render with. There are a lot of upsides to running it through the web platform (the big one is that I can give people a link and they can click it, rather than convince them to run an app, but there are others, too). There are downsides: performance is heavily variable. A new Chrome can launch and my performance can be 5x worse than before, which is why I now always test in Canary to make sure I'm ahead of all issues. In Chrome, the WebGL layer is pretty solid, but I still find plenty of bugs and performance issues (e.g. looking at a profile unearthed this very simple issue causing browser resizing to be way slower than it needed to be https://bugs.chromium.org/p/chromium/issues/detail?id=1103473 https://bugs.chromium.org/p/chromium/issues/detail?id=110347... ). Firefox is quite a bit slower and has a bit more draw call overhead than Chrome (I'm guessing they run validation on the main thread rather than an IPC process, causing JS to block) Most of the performance problems I encounter are actually JS-related, it's super easy to be knocked off of a fast path by complete accident, and there aren't good tools to know what I'm doing wrong. Math and ALU is plenty fast -- doing matrix multiplication on the CPU has never been a bottleneck, and you actually want that more on the CPU so that the GPU doesn't have to run a matrix mul for every pixel. Uniform data computation belongs on the CPU. My big thing that I fight is the garbage collector, and you can see the awkward "manual register allocation" code style I sometimes resort to to make sure my allocations per-frame are super minimal, especially in fast math code. It doesn't look like traditional ergonomic JS code: https://github.com/magcius/noclip.website/blob/master/src/SuperMarioGalaxy/Shadow.ts#L249-L252 https://github.com/magcius/noclip.website/blob/master/src/Su... I could go on if wanted but this comment is already getting pretty long.

jfkebwjsbx 6y ago
That sounds like a development nightmare like the one of the IE6 era, and even worse for supporting customers. Basically you are saying code performance is nondeterministic across your user base and across time too? I am glad WebGL is a thing for pages that need some 3D widgets where performance is not a big deal. But for general software or games? I will keep my native software.