Swap start/finish order for rendering #630
Conversation
|
I'm still able to test Windows build. I'll check it this week. |
|
I guess it fixes #343 |
|
Can this be rebased and retested? |
|
@CedricGuillemet you did test this a while back on Windows and something wasn't working, correct? Do you recall what the issue was? Can you add some notes to this PR discussion? |
Sorry, I don't remember testing this PR. I can add that to my todo list |
|
Found a private chat between us back in January and you said:
No additional discussion after that, so I think that is as far as we got with testing on Windows and then the PR was put on hold. |
In this change, the order of start/finish for rendering (
Graphics::DeviceandGraphics::DeviceUpdate) is swapped (similar to what was already done in the BN Playground app). This is more efficient as it results in less blocked time on the main thread, and should also allow the JS thread to start its per-frame work earlier. Without these changes, there can be more "fighting" for CPU time between BN and platform UI. I tested these changes by adding a large React NativeFlatListinto the main screen of the Playground app, and testing how scrolling theFlatListwhile interacting with the scene affected performance. Just looking at the frame rate, it seems like I get about a 10% improvement in performance (both Android and iOS). I expect we'd get better gains on Android with future work moving the rendering off the main thread entirely.Testing
I tested pretty thoroughly with the Playground app on Android and iOS. I wasn't able to get a Windows build working (haven't tried in a long time), so I haven't tested on Windows (could use some help here 🙏🏻).
Fixes #343