5 ms·

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

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.
        Jasper_ 7y ago
        Speed should indeed be the default behavior, which is why I'm so upset at React being so slow. It really shouldn't be; computers are fast. We shouldn't have to multi-thread updating 2,000 objects to get performance.
    - csande17 7y ago
      > what you see above [the 2000-cube demo] simply would not be possible without scheduling, that is a fact. you can't expect any renderer to handle that amount of stress, it's a matter of capacity. https://twitter.com/0xca0a/status/1200121269339000838 https://twitter.com/0xca0a/status/1200121269339000838
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

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.
      - Jasper_ 7y ago
        Speed should indeed be the default behavior, which is why I'm so upset at React being so slow. It really shouldn't be; computers are fast. We shouldn't have to multi-thread updating 2,000 objects to get performance.
  - csande17 7y ago
    > what you see above [the 2000-cube demo] simply would not be possible without scheduling, that is a fact. you can't expect any renderer to handle that amount of stress, it's a matter of capacity. https://twitter.com/0xca0a/status/1200121269339000838 https://twitter.com/0xca0a/status/1200121269339000838

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