The latest updates on your projects. Learn more about Vercel for Git ↗︎

Hey!

However, this detour helped me identify the real bottleneck. I noticed that although pointer events no longer triggered React re-renders, there was still some unusual behavior. After some more investigation, I found that the App component frequently changes the --ui-pointerEvent CSS variable to block other elements' interactivity, and applying these changes was the root cause of the lags.

My proposed solution is to remove these changes while maintaining the same UX (i.e., no interaction with outside elements during canvas interaction). During a canvas pointer up event, we capture the pointer events to the canvas itself. This ensures that all other outside elements will be non-interactive until a pointer up event. I tested this solution and it provides the same UX as before, though there could be some edge cases I'm not aware of. Unfortunately, I have noticed the tests are failing because pepjs, the library that polyfills pointer events to jsdom does not properly support the capturing phase for pointer events. Still, I think this idea is worth considering at least.

Interesting find, and solution! I've mocked the API for tests since we weren't testing this part of the UI behavior anyway. We'll see if it bites us in the future.

I've also kept the old logic in case the setPointerCapture is not supported — while it has a good browser support, on mobile it's not quite universal, and a pointer handling shouldn't be something we'll completely break in those cases.

--

I'll need to go through the LibraryMenu changes tomorrow, but so far, looking good 👍.

Alright, so first I removed the pendingElements update optimizations you made because there were issues with updates (e.g. when you change color of current selection, it wouldn't catch the change), and also it seemed it wasn't worth the effort.

But then I realized that in multiplayer scenarios it will rerender the LibraryMenuContent on every remote change because cursorButton will be up most of the time, so I reintroduced the memoization but made it a bit more robust — which also made it more complicated / slower. But it seems there's some non-trivial perf benefit.

That said, there are some non-intuitive things happening, such as that without the optim (technically with the optim as well) there are more rerenders when the remote client is dragging an element you don't have selected (which should bail) as opposed to editing your own selection. Unclear why, something that can be investigated later.

Thus, the quest for making Library sidebar more optimized continues, I would say — but I'm glad we've made a good step toward optimizing it :).

Thanks! ❤️

Suspect Issues

This pull request was deployed and Sentry observed the following issues:

• ‼️ ReferenceError: structuredClone is not defined updateElbowArrowPoints(packages/excalidraw/elem... View Issue

_{Did you find this useful? React with a 👍 or 👎}