I'd like the spec to say a bit more about how "desynchronized" affects event handling, if at all. Presumably the page still has to run JS to handle pointer events and call canvas API; does that part follow the normal HTML event loop rules? If so, isn't canvas update rate still limited by how responsive the event loop is?

[annevk]

I'd like the spec to say a bit more about how "desynchronized" affects event handling, if at all. Presumably the page still has to run JS to handle pointer events and call canvas API; does that part follow the normal HTML event loop rules? If so, isn't canvas update rate still limited by how responsive the event loop is?

Originally posted by @smfr in #4087 (comment)

[annevk]

cc @YellowDoge

[wffurr]

The "desynchronized" attribute does not affect event handling in any way. Mentions of "input processing" were removed from the spec after requests to do so: #4360 (comment)

In general, yes, the canvas update rate is still limited by the event loop. As long as there's no major blocking events happening in the event loop, there is still a substantial gain in elapsed wall time between a stylus touching the screen and the canvas changing color, due to bypassing the compositor and using direct scanout hardware to the display.

The desynchronized attribute can be combined with a number of other techniques to mitigate event loop blocking: pointerrawupdate, offscreen canvas, passive event listeners, sending input events to a worker, careful control of main thread JS, etc.

A desynchronized canvas is just one technique of many that can be used together to write a high performance drawing app or other "event-to-display" latency sensitive app.