8 ms·

From a marketing standpoint, I'm not sure demos like this that draw comparisons between JavaScript frameworks and 3D game engines are a great idea. The author d

From a marketing standpoint, I'm not sure demos like this that draw comparisons between JavaScript frameworks and 3D game engines are a great idea. The author describes updating 2000 cubes every frame as an "impossible amount of load", and claims that React will soon "run circles around even the best performing manual WebGL apps". Here's Unity maintaining a smooth framerate while updating three times that many cubes: https://www.youtube.com/watch?v=qVMfKJfsHQg https://www.youtube.com/watch?v=qVMfKJfsHQg Unlike the React demo, all of the cubes actually move each frame (it's not "rescheduling" updates to later frames like React Concurrent Mode does), and it's doing a complex physics simulation to decide where the cubes should go.

underwater 7y ago
React concurrent makes a lot of sense for UI elements, which are complex and self contained and sporadically updated. Whereas a game engine is much more about raw speed, and every element is updated on each tick. I would be surprised if the overhead of React and concurrent mode bookkeeping were worth it for a game engine.
Jasper_ 7y ago
Yeah, maintaining state for 2000 elements is not a hard problem. I've written CPU particle systems which handle ~10k particles per frame, some of which even run entirely in the browser. This shot from Super Mario Galaxy simulates around 3,000 particles, on top of all the other bone/joint animations that are happening. Performance like this is possible in a web browser, but you wouldn't think so given how popular React and ThreeJS are. https://noclip.website/#smg/AstroGalaxy;AAI4t49Qk^u9Ld&YUm,m_W-zy_4~(x_UcUO6UP@]=WR2Z39kY1tTqnNC9G:U0+^8 https://noclip.website/#smg/AstroGalaxy;AAI4t49Qk^u9Ld&YUm,m...
- onion2k 7y ago
  Performance like this is possible in a web browser, but you wouldn't think so given how popular React and ThreeJS are. Updating the state of thousands of DOM nodes at a steady 16ms per frame in a browser is hard enough that you have to go beyond "just update them all every frame" like in a simple particle system. To go fast you have to move to working out what needs to update based on what changed in the state. Most web app developers don't want to have to think too hard about how it gets on the screen. They, very reasonably in my opinion, want to work on the app logic itself instead. Unfortunately that's how we end up with janky UIs. If React's concurrent mode can just be fast by default by spreading out updates if the framerate is falling that's good for everyone.
  - Jasper_ 7y ago
    > Updating the state of thousands of DOM nodes at a steady 16ms per frame in a browser is hard enough No, it's really not. I've done it before, and profiled it. 16ms is a super long time to a computer. You should easily be able to update tens, if not hundreds of thousands of DOM nodes, assuming you aren't doing anything weird like blocking on layout in one of them. Let's aim for frameworks that are in the ballpark of peak raw performance, before we look to parallelism and multi-threading as a solution. That someone possibly had the mistaken belief that this was peak performance for a hand-rolled WebGL codebase shows how low and out-of-touch our expectations for performance really are.
    - onion2k 7y ago
      That someone possibly had the mistaken belief that this was peak performance for a hand-rolled WebGL codebase.. No one thought that though. This is a demo of good performance using a web framework on top of a WebGL framework. It's showing that a future version of React will make building a solid 60fps web app UI is within the reach of most web developers. Sure, you can hand-roll code to get that performance today if you know how, but this is about putting that performance in the hands of developers who can't (or, more often, aren't given the resources to). To argue that is unnecessary or actually bad is ridiculous. Libraries that make it easier to build better apps are universally good things.
      - Jasper_ 7y ago
        The OP literally tweeted this: > I'm pretty sure it will run circles around even the best performing manual three or webGL apps out there soon. https://twitter.com/0xca0a/status/1199997563396612096 https://twitter.com/0xca0a/status/1199997563396612096
        cercatrova 7y ago
        Correct; however, the tweet author's mistaken sense of arrogance does not invalidate the points made by your parent comment. To steel-man that argument, having this speed be default behavior allows developers to create much better UX than currently, at least on terms of responsiveness.
- winter_blue 7y ago
  > https://noclip.website https://noclip.website Very cool website! I just noticed you're the one behind it[1]! Just curious: when people contribute textures toy our project, do they have to get permission from the video game publisher first? Also, how hard is the process of extracting the textures of a video game? Is there effort involved in stitching multiple DDS/other texture files together, so that it can presentable on your website? [1] https://github.com/magcius/noclip.website https://github.com/magcius/noclip.website
  - Jasper_ 7y ago
    The browser reads as close to raw game data as it can get (I have written my own data extractors in some cases if the data is too big, or doesn't have a natural filesystem so that people can't download raw ROMs). In the case of the Galaxy levels, it's reading the raw files as shipped on the Wii disc. I have my own renderer and emulation tech [0]. It's the only way to ensure accuracy to a degree I'm happy with. For textures specifically, they're stored in the Wii's texture formats, so I have my own texture decoder [1]. I did not get permission from the original game developers, but I think I'm doing everything here in good faith, out of love for the source material, and that I'm not replacing the experience of playing the game for yourself. The developers of Fez specifically retweeted a post about it on the official Twitter. [0] https://github.com/magcius/noclip.website/blob/master/src/gx/gx_material.ts https://github.com/magcius/noclip.website/blob/master/src/gx... [1] https://github.com/magcius/noclip.website/blob/master/src/assembly/gx_texture_as.ts https://github.com/magcius/noclip.website/blob/master/src/as...
- jimbo1qaz 7y ago
  I'm in a browser window slightly below 1920x1080, with an AMD RX Vega 10 mobile GPU. The page renders at 20-30fps in Chrome, and 10-20fps in Firefox.
  - Jasper_ 7y ago
    If you resize the browser window smaller, does it get faster? If so, sounds like you're GPU limited, which still proves that the bottleneck isn't the CPU, which is what we're talking about here -- CPU performance of React vs. non-React.
- jbverschoor 7y ago
  Thank you, finally a sane perso who understands how blazing fast computers are
JMTQp8lwXL 7y ago
I very much respect and appreciate this perspective, however I think it's important to consider the context of what React is used for. It's made for things like building store fronts and UIs for SaaS companies. Stuff that's list of things, and has some form input. It isn't really used for games. Not to say that React couldn't be used for that, but most people aren't using React while also placing extreme pressure on the GPU. Also, I don't know if people want an e-shopping experience that has the visual complexity of feeling like they're playing a video game.
- HereBeBeasties 7y ago
  It's also used quite extensively for data visualisation roles that D3 has traditionally been king of, in fact often alongside D3's libraries for calculating axis tick marks, colour scales, etc. To that end, you actually do end up with thousands of DOM nodes quite often.
- dragonwriter 7y ago
  > It isn't really used for games React VR is a thing, though.
- deltron3030 7y ago
  React came out the same year they bought Oculus, so there might be a long term plan to first conquer the world of webdev, get the devs used to that paradigm and then integrate it with VR and funnel the devs to their own platform in the long run. This could explain the unneccessary complexity of the vdom for normal websites and apps. In VR you need high staedy framerates, the vdom could be used to shorten the round trip from client to server, as some kind of framebuffer.
  - Jasper_ 7y ago
    what? both the DOM and the VDOM are client-side data structures, what are you even talking about
    - deltron3030 7y ago
flohofwoe 7y ago
Here's a WebGL+WASM experiment I did a little while ago, all object positions are CPU updated. It goes to a million objects at 60Hz without breaking a sweat on the desktop machine I'm testing here (1 million is where the demo stops adding objects), all very simple and straightforward single-threaded code. There are some stuttering frames every 300k objects or so, I guess this is when WebGL needs to grow buffers under the hood. Hoping for WebGPU to fix those problems. https://floooh.github.io/oryol/wasm/Instancing.html https://floooh.github.io/oryol/wasm/Instancing.html No matter how you look at it, moving a few thousand things around on screen really isn't all that impressive, you just have to know the weaknesses of the platform (WebGL's is a high draw call overhead) and work around them.
- cocoflunchy 7y ago
  This is the only answer I've found in this thread that actually demonstrates the point everyone is making, it's buttery smooth on my iPhone SE (!) up to 300k elements.
- tgv 7y ago
  Amazing. My MBP/Firefox still had 50% idle with a frame request every 8.6ms at 1M particles. React is a bit of a resource hog, and all the article shows is that modern processors are really powerful.
  - earthboundkid 7y ago
    It was around 16ms on an iPad mini 5. Computers are fast.
- Jasper_ 7y ago
  Indeed, but we're not even talking about WebGL's high draw call overhead (that overhead is constant between all the demos!), just the overhead of updating ThreeJS's view of the world on the main thread, which should be a matrix mul at the most. The rest of the overhead from ThreeJS rendering, and from WebGL, that's the same in both demos! Matrix multiplication should not have to be scheduled!
gigatexal 7y ago
Does it even matter? React is becoming the defacto standard for the web it seems.
jkoudys 7y ago
It's a challenge with any demo, because examples in software are always by definition contrived, or too specific to be relatable. There's always going to be some user base that can relate your example better to their challenges than others.

underwater 7y ago

React concurrent makes a lot of sense for UI elements, which are complex and self contained and sporadically updated. Whereas a game engine is much more about raw speed, and every element is updated on each tick. I would be surprised if the overhead of React and concurrent mode bookkeeping were worth it for a game engine.

Jasper_ 7y ago

Yeah, maintaining state for 2000 elements is not a hard problem. I've written CPU particle systems which handle ~10k particles per frame, some of which even run entirely in the browser. This shot from Super Mario Galaxy simulates around 3,000 particles, on top of all the other bone/joint animations that are happening. Performance like this is possible in a web browser, but you wouldn't think so given how popular React and ThreeJS are. https://noclip.website/#smg/AstroGalaxy;AAI4t49Qk^u9Ld&YUm,m_W-zy_4~(x_UcUO6UP@]=WR2Z39kY1tTqnNC9G:U0+^8 https://noclip.website/#smg/AstroGalaxy;AAI4t49Qk^u9Ld&YUm,m...

onion2k 7y ago
Performance like this is possible in a web browser, but you wouldn't think so given how popular React and ThreeJS are. Updating the state of thousands of DOM nodes at a steady 16ms per frame in a browser is hard enough that you have to go beyond "just update them all every frame" like in a simple particle system. To go fast you have to move to working out what needs to update based on what changed in the state. Most web app developers don't want to have to think too hard about how it gets on the screen. They, very reasonably in my opinion, want to work on the app logic itself instead. Unfortunately that's how we end up with janky UIs. If React's concurrent mode can just be fast by default by spreading out updates if the framerate is falling that's good for everyone.
- Jasper_ 7y ago
  > Updating the state of thousands of DOM nodes at a steady 16ms per frame in a browser is hard enough No, it's really not. I've done it before, and profiled it. 16ms is a super long time to a computer. You should easily be able to update tens, if not hundreds of thousands of DOM nodes, assuming you aren't doing anything weird like blocking on layout in one of them. Let's aim for frameworks that are in the ballpark of peak raw performance, before we look to parallelism and multi-threading as a solution. That someone possibly had the mistaken belief that this was peak performance for a hand-rolled WebGL codebase shows how low and out-of-touch our expectations for performance really are.
  - onion2k 7y ago
    That someone possibly had the mistaken belief that this was peak performance for a hand-rolled WebGL codebase.. No one thought that though. This is a demo of good performance using a web framework on top of a WebGL framework. It's showing that a future version of React will make building a solid 60fps web app UI is within the reach of most web developers. Sure, you can hand-roll code to get that performance today if you know how, but this is about putting that performance in the hands of developers who can't (or, more often, aren't given the resources to). To argue that is unnecessary or actually bad is ridiculous. Libraries that make it easier to build better apps are universally good things.
    - Jasper_ 7y ago
      The OP literally tweeted this: > I'm pretty sure it will run circles around even the best performing manual three or webGL apps out there soon. https://twitter.com/0xca0a/status/1199997563396612096 https://twitter.com/0xca0a/status/1199997563396612096
      - cercatrova 7y ago
        Correct; however, the tweet author's mistaken sense of arrogance does not invalidate the points made by your parent comment. To steel-man that argument, having this speed be default behavior allows developers to create much better UX than currently, at least on terms of responsiveness.
winter_blue 7y ago
> https://noclip.website https://noclip.website Very cool website! I just noticed you're the one behind it[1]! Just curious: when people contribute textures toy our project, do they have to get permission from the video game publisher first? Also, how hard is the process of extracting the textures of a video game? Is there effort involved in stitching multiple DDS/other texture files together, so that it can presentable on your website? [1] https://github.com/magcius/noclip.website https://github.com/magcius/noclip.website
- Jasper_ 7y ago
  The browser reads as close to raw game data as it can get (I have written my own data extractors in some cases if the data is too big, or doesn't have a natural filesystem so that people can't download raw ROMs). In the case of the Galaxy levels, it's reading the raw files as shipped on the Wii disc. I have my own renderer and emulation tech [0]. It's the only way to ensure accuracy to a degree I'm happy with. For textures specifically, they're stored in the Wii's texture formats, so I have my own texture decoder [1]. I did not get permission from the original game developers, but I think I'm doing everything here in good faith, out of love for the source material, and that I'm not replacing the experience of playing the game for yourself. The developers of Fez specifically retweeted a post about it on the official Twitter. [0] https://github.com/magcius/noclip.website/blob/master/src/gx/gx_material.ts https://github.com/magcius/noclip.website/blob/master/src/gx... [1] https://github.com/magcius/noclip.website/blob/master/src/assembly/gx_texture_as.ts https://github.com/magcius/noclip.website/blob/master/src/as...
jimbo1qaz 7y ago
I'm in a browser window slightly below 1920x1080, with an AMD RX Vega 10 mobile GPU. The page renders at 20-30fps in Chrome, and 10-20fps in Firefox.
- Jasper_ 7y ago
  If you resize the browser window smaller, does it get faster? If so, sounds like you're GPU limited, which still proves that the bottleneck isn't the CPU, which is what we're talking about here -- CPU performance of React vs. non-React.
jbverschoor 7y ago
Thank you, finally a sane perso who understands how blazing fast computers are

JMTQp8lwXL 7y ago

I very much respect and appreciate this perspective, however I think it's important to consider the context of what React is used for. It's made for things like building store fronts and UIs for SaaS companies. Stuff that's list of things, and has some form input. It isn't really used for games. Not to say that React couldn't be used for that, but most people aren't using React while also placing extreme pressure on the GPU. Also, I don't know if people want an e-shopping experience that has the visual complexity of feeling like they're playing a video game.

HereBeBeasties 7y ago
It's also used quite extensively for data visualisation roles that D3 has traditionally been king of, in fact often alongside D3's libraries for calculating axis tick marks, colour scales, etc. To that end, you actually do end up with thousands of DOM nodes quite often.
dragonwriter 7y ago
> It isn't really used for games React VR is a thing, though.
deltron3030 7y ago
React came out the same year they bought Oculus, so there might be a long term plan to first conquer the world of webdev, get the devs used to that paradigm and then integrate it with VR and funnel the devs to their own platform in the long run. This could explain the unneccessary complexity of the vdom for normal websites and apps. In VR you need high staedy framerates, the vdom could be used to shorten the round trip from client to server, as some kind of framebuffer.
- Jasper_ 7y ago
  what? both the DOM and the VDOM are client-side data structures, what are you even talking about
  - deltron3030 7y ago

flohofwoe 7y ago

Here's a WebGL+WASM experiment I did a little while ago, all object positions are CPU updated. It goes to a million objects at 60Hz without breaking a sweat on the desktop machine I'm testing here (1 million is where the demo stops adding objects), all very simple and straightforward single-threaded code. There are some stuttering frames every 300k objects or so, I guess this is when WebGL needs to grow buffers under the hood. Hoping for WebGPU to fix those problems. https://floooh.github.io/oryol/wasm/Instancing.html https://floooh.github.io/oryol/wasm/Instancing.html No matter how you look at it, moving a few thousand things around on screen really isn't all that impressive, you just have to know the weaknesses of the platform (WebGL's is a high draw call overhead) and work around them.

cocoflunchy 7y ago
This is the only answer I've found in this thread that actually demonstrates the point everyone is making, it's buttery smooth on my iPhone SE (!) up to 300k elements.
tgv 7y ago
Amazing. My MBP/Firefox still had 50% idle with a frame request every 8.6ms at 1M particles. React is a bit of a resource hog, and all the article shows is that modern processors are really powerful.
- earthboundkid 7y ago
  It was around 16ms on an iPad mini 5. Computers are fast.
Jasper_ 7y ago
Indeed, but we're not even talking about WebGL's high draw call overhead (that overhead is constant between all the demos!), just the overhead of updating ThreeJS's view of the world on the main thread, which should be a matrix mul at the most. The rest of the overhead from ThreeJS rendering, and from WebGL, that's the same in both demos! Matrix multiplication should not have to be scheduled!

gigatexal 7y ago

Does it even matter? React is becoming the defacto standard for the web it seems.

jkoudys 7y ago

It's a challenge with any demo, because examples in software are always by definition contrived, or too specific to be relatable. There's always going to be some user base that can relate your example better to their challenges than others.