events: explore using getCoalescedEvents

[mimecuvalo]

Wanted to open a discussion on getCoalescedEvents and see if it's worth integrating into the canvas. The videos below show trying to draw with a CPU 20x slowdown.

(I know we've talked about getPredictedEvents but that's a separate topic)
Testbed: https://patrickhlauke.github.io/touch/coalesced-predicted-events/

Before:

Kapture.2025-03-04.at.17.07.35.mp4

After:

Kapture.2025-03-04.at.17.09.11.mp4

Change type

• bugfix
• improvement
• feature
• api
• other

Release notes

• Improve draw fluidity on slower CPUs by using getCoalescedEvents.

[vercel]

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

Name	Status	Preview	Updated (UTC)
examples	✅ Ready (Inspect)	Visit Preview	Mar 11, 2025 11:28am

1 Skipped Deployment

Name	Status	Preview	Updated (UTC)
tldraw-docs	⬜️ Ignored (Inspect)	Visit Preview	Mar 11, 2025 11:28am

[SomeHats]

this is so fucking cool??????

[SomeHats]

so, thinking about this a bit more... do we know of a reason we shouldn't do this?

[mimecuvalo]

so, thinking about this a bit more... do we know of a reason we shouldn't do this?

There could be a hesititation around when there's a lot of shapes being manipulated, say, selecting a lot of shapes on the canvas and moving them around all at once, maybe that affects perf? @MitjaBezensek wdyt?

Or, well, say using the Hand tool and doing the same, moving the canvas around.

[MitjaBezensek]

I think this definitely makes sense for events where high precision brings some benefits - like while drawing since it allows us to make drawings that more closely follow the user's input. For other cases it might actually be worse. The fact that browser coalesces events means that it determined the the device is not capable enough to process all of them, so it starts coalescing them.

We did run into some problems when we tried something like this before, see this PR, especially the coalescing part:
#3223

[mimecuvalo]

We did run into some problems when we tried something like this before

Let's dig into that a bit , specifically, in the PR you reference it says:

Often a state node required information from elsewhere in the app when processing an event (such as camera position or page point, which is derived from the camera position)

• Was that only an issue for things like resize? Or did it also affect drawing?
• I'm also wondering if that was maybe particular to the custom coalescing that was happening vs. this native browser coalescing that we're just putting in the dispatch queue.
• wdyt if we were to only look at getCoalescedEvents when we're specifically in the draw/highlight tools?