4 ms·

> If you give it an impossible load, so many render requests that it must choke, it will start to manage these requests to maintain a stable 60fps, by updating

> If you give it an impossible load, so many render requests that it must choke, it will start to manage these requests to maintain a stable 60fps, by updating components virtually and letting them retain their visual state Does that mean if you try to update too many things it will simply... not update them in order to maintain 60fps? That does not seem ideal. In this particular example, a bunch of random objects updated every frame, will that result in a "spiral of death"? Meaning every frame M transform requests are made. But it will only process N (where N < M) requests. Or does it drop parts of the queue if it didn't process a transform before receiving a second update for the same transform? Is updating 2000 boxes per second really considered an "impossible" amount to update? That seems like a shockingly small number. Edit: I don’t understand the downvotes. My question on understanding behavior is perfectly reasonable. I don’t understand how this new technology works. What is it doing under the hood?

onion2k 7y ago
Is updating 2000 boxes per second really considered an "impossible" amount to update? That seems like a shockingly small number. That's not what's happening in the demo. It's effectively updating 2000 virtual DOM nodes at 60 frames a second by scheduling updates so as many things are updated in each 16ms frame as possible. It'll scale with the device. If you have a beast of a computer it might update all 2000 every frame. If you're on a $100 smart phone it'll schedule the updates across several frames. In the demo each node is a three.js box geometry - react-three-fiber uses react's virtual DOM reconciler to update state on three.js things. That doesn't have to be the case though. The nodes could be HTML elements or SVG things or any other browser renderable item. React doesn't care. What the demo really shows is that concurrent mode React moves the bottleneck out of the framework and back to the browser - how fast the UI can be updated will be down to the browser instead of what the JS framework can do. That's a really big deal. It'll make writing performant UIs a lot easier which is good for everyone.
- setr 7y ago
  I believe the question is that if I generate 2000 updates a second, but its applying those 2000 updates over 4 seconds (applying 500 updates a second to maintain 60fps), then at second 1 I have 2000 updates remaining(+2000 new) At second 2 I have 3500 updates remaining (+2000 new, -500 processed) At second 3 I have 5000 updates remaining (+2000 new, -500 processed) That is, my backlog will indefinitely grow larger, unless it's dropping updates.
  - onion2k 7y ago
    Reacts concurrent mode isn't a magic fix for apps that literally want to do more than the computer can cope with. It's a way of distributing changes across frames so the browser isn't doing a huge update in one frame and then idling in the next 5. That's very useful for 99.9% of web UIs right now. If your app is in that 0.1% then you'll still have some perf work to do yourself.
  - kilburn 7y ago
    You cannot generate 2000 updates a second if your computer cannot handle them. Javascript runs a "main loop" that just executes "tasks". Tasks are chunks of synchronous code, and are not preemtible. Let's say you have a "generator" task that generates 2_000 "update" tasks. The way this works is: 1. "generator" schedules 2_000 "update" tasks to run as soon as possible, and schedules another "generator" task for 1s from now. 2. The browser starts running "update" tasks one after the other as fast as it can. 3a. If the "update" tasks are all done 1s after the previous "generator" task, then the browser will run "generator" again. 3b. If they are not done, the browser will continue running "update" tasks and only invoke "generator" again _after_ it has finished with all the "update" tasks, be it 1 or 100 seconds after the previous "generator" task.
    - mlsarecmg 7y ago
      You can. This is what the demo does. The scheduler takes that amount and schedules is, which is the point. Every game engine does that (for instance frustrum culling). Games face an impossible amount of data, and schedule it. This is also true for native dev where you have priority dispatchers and threads. What React does is exciting because it schedules at the very root.
- Jasper_ 7y ago
  > If you have a beast of a computer it might update all 2000 every frame. The point is that you shouldn't need a beast of a computer to update 2,000 boxes. That's way outside of the performance profile I expect from any recent CPU.
deleted 7y ago
[deleted]
mlsarecmg 7y ago
Yes, but it scales with the environment and device capabilities. Watch this, it explains it in detail: https://www.youtube.com/watch?v=nLF0n9SACd4 https://www.youtube.com/watch?v=nLF0n9SACd4

onion2k 7y ago

Is updating 2000 boxes per second really considered an "impossible" amount to update? That seems like a shockingly small number. That's not what's happening in the demo. It's effectively updating 2000 virtual DOM nodes at 60 frames a second by scheduling updates so as many things are updated in each 16ms frame as possible. It'll scale with the device. If you have a beast of a computer it might update all 2000 every frame. If you're on a $100 smart phone it'll schedule the updates across several frames. In the demo each node is a three.js box geometry - react-three-fiber uses react's virtual DOM reconciler to update state on three.js things. That doesn't have to be the case though. The nodes could be HTML elements or SVG things or any other browser renderable item. React doesn't care. What the demo really shows is that concurrent mode React moves the bottleneck out of the framework and back to the browser - how fast the UI can be updated will be down to the browser instead of what the JS framework can do. That's a really big deal. It'll make writing performant UIs a lot easier which is good for everyone.

setr 7y ago
I believe the question is that if I generate 2000 updates a second, but its applying those 2000 updates over 4 seconds (applying 500 updates a second to maintain 60fps), then at second 1 I have 2000 updates remaining(+2000 new) At second 2 I have 3500 updates remaining (+2000 new, -500 processed) At second 3 I have 5000 updates remaining (+2000 new, -500 processed) That is, my backlog will indefinitely grow larger, unless it's dropping updates.
- onion2k 7y ago
  Reacts concurrent mode isn't a magic fix for apps that literally want to do more than the computer can cope with. It's a way of distributing changes across frames so the browser isn't doing a huge update in one frame and then idling in the next 5. That's very useful for 99.9% of web UIs right now. If your app is in that 0.1% then you'll still have some perf work to do yourself.
- kilburn 7y ago
  You cannot generate 2000 updates a second if your computer cannot handle them. Javascript runs a "main loop" that just executes "tasks". Tasks are chunks of synchronous code, and are not preemtible. Let's say you have a "generator" task that generates 2_000 "update" tasks. The way this works is: 1. "generator" schedules 2_000 "update" tasks to run as soon as possible, and schedules another "generator" task for 1s from now. 2. The browser starts running "update" tasks one after the other as fast as it can. 3a. If the "update" tasks are all done 1s after the previous "generator" task, then the browser will run "generator" again. 3b. If they are not done, the browser will continue running "update" tasks and only invoke "generator" again _after_ it has finished with all the "update" tasks, be it 1 or 100 seconds after the previous "generator" task.
  - mlsarecmg 7y ago
    You can. This is what the demo does. The scheduler takes that amount and schedules is, which is the point. Every game engine does that (for instance frustrum culling). Games face an impossible amount of data, and schedule it. This is also true for native dev where you have priority dispatchers and threads. What React does is exciting because it schedules at the very root.
Jasper_ 7y ago
> If you have a beast of a computer it might update all 2000 every frame. The point is that you shouldn't need a beast of a computer to update 2,000 boxes. That's way outside of the performance profile I expect from any recent CPU.

deleted 7y ago

[deleted]

mlsarecmg 7y ago

Yes, but it scales with the environment and device capabilities. Watch this, it explains it in detail: https://www.youtube.com/watch?v=nLF0n9SACd4 https://www.youtube.com/watch?v=nLF0n9SACd4