Tldraw/apps/examples/e2e/tests/test-canvas-events.spec.ts

154 wiersze
3.9 KiB
TypeScript
Czysty Zwykły widok Historia

import test, { expect, Page } from '@playwright/test'
import { Editor } from 'tldraw'
import { setupPage } from '../shared-e2e'
declare const __tldraw_editor_events: any[]
// We're just testing the events, not the actual results.
let page: Page
declare const editor: Editor
test.describe('Canvas events', () => {
test.beforeAll(async ({ browser }) => {
page = await browser.newPage()
await setupPage(page)
})
test.describe('pointer events', () => {
test('pointer down', async () => {
await page.mouse.move(200, 200) // to kill any double clicks
await page.mouse.move(100, 100)
await page.mouse.down()
Input buffering (#3223) This PR buffs input events. ## The story so far In the olde days, we throttled events from the canvas events hook so that a pointer event would only be sent every 1/60th of a second. This was fine but made drawing on the iPad / 120FPS displays a little sad. Then we removed this throttle. It seemed fine! Drawing at 120FPS was great. We improved some rendering speeds and tightened some loops so that the engine could keep up with 2x the number of points in a line. Then we started noticing that iPads and other screens could start choking on events as it received new inputs and tried to process and render inputs while still recovering from a previous dropped frame. Even worse, on iPad the work of rendering at 120FPS was causing the browser to throttle the app after some sustained drawing. Yikes! ### Batching I did an experimental PR (#3180) to bring back batching but do it in the editor instead. What we would do is: rather than immediately processing an event when we get it, we would instead put the event into a buffer. On the next 60FPS tick, we would flush the buffer and process all of the events. We'd have them all in the same transaction so that the app would only render once. ### Render batching? We then tried batching the renders, so that the app would only ever render once per (next) frame. This added a bunch of complexity around events that needed to happen synchronously, such as writing text in a text field. Some inputs could "lag" in a way familiar to anyone who's tried to update an input's state asynchronously. So we backed out of this. ### Coalescing? Another idea from @ds300 was to "coalesce" the events. This would be useful because, while some interactions like drawing would require the in-between frames in order to avoid data loss, most interactions (like resizing) didn't actually need the in-between frames, they could just use the last input of a given type. Coalescing turned out to be trickier than we thought, though. 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), and so the coalesced events would need to also include this information or else the handlers wouldn't work the way they should when processing the "final" event during a tick. So we backed out of the coalescing strategy for now. Here's the [PR that removes](https://github.com/tldraw/tldraw/pull/3223/commits/937469d69d4474fe9d1ff98604acb8f55a49f3fa) it. ### Let's just buffer the fuckers So this PR now should only include input buffering. I think there are ways to achieve the same coalescing-like results through the state nodes, which could gather information during the `onPointerMove` handler and then actually make changes during the `onTick` handler, so that the changes are only done as many time as necessary. This should help with e.g. resizing lots of shapes at once. But first let's land the buffering! --- Mitja's original text: This PR builds on top of Steve's [experiment PR](https://github.com/tldraw/tldraw/pull/3180) here. It also adds event coalescing for [`pointerMove` events](https://github.com/tldraw/tldraw/blob/mitja/input-buffering/packages/editor/src/lib/editor/Editor.ts#L8364-L8368). The API is [somewhat similar ](https://developer.mozilla.org/en-US/docs/Web/API/PointerEvent/getCoalescedEvents) to `getCoalescedEvent`. In `StateNodes` we register an `onPointerMove` handler. When the event happens it gets called with the event `info`. There's now an additional field on `TLMovePointerEvent` called `coalescedInfo` which includes all the events. It's then on the user to process all of these. I decided on this API since it allows us to only expose one event handler, but it still gives the users access to all events if they need them. We would otherwise either need to: - Expose two events (coalesced and non-coalesced one and complicate the api) so that state nodes like Resizing would not be triggered for each pointer move. - Offer some methods on the editor that would allow use to get the coalesced information. Then the nodes that need that info could request it. I [tried this](https://github.com/tldraw/tldraw/pull/3223/commits/9ad973da3aa287e7974067ac923193530d29c188#diff-32f1de9a5a9ec72aa49a8d18a237fbfff301610f4689a4af6b37f47af435aafcR67), but it didn't feel good. This also complicated the editor inputs. The events need to store information about the event (like the mouse position when the event happened for `onPointerMove`). But we cannot immediately update inputs when the event happens. To make this work for `pointerMove` events I've added `pagePoint`. It's [calculated](https://github.com/tldraw/tldraw/pull/3223/files#diff-980beb0aa0ee9aa6d1cd386cef3dc05a500c030638ffb58d45fd11b79126103fR71) when the event triggers and then consumers can get it straight from the event (like [Drawing](https://github.com/tldraw/tldraw/pull/3223/files#diff-32f1de9a5a9ec72aa49a8d18a237fbfff301610f4689a4af6b37f47af435aafcR104)). ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [x] `sdk` — Changes the tldraw SDK - [ ] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Add a step-by-step description of how to test your PR here. 4. - [ ] Unit Tests - [ ] End to end tests ### Release Notes - Add a brief release note for your PR here. --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-02 14:29:14 +00:00
await page.waitForTimeout(20)
expect(await page.evaluate(() => __tldraw_editor_events.at(-1))).toMatchObject({
target: 'canvas',
type: 'pointer',
name: 'pointer_down',
})
})
test('pointer move', async () => {
await page.mouse.move(200, 200) // to kill any double clicks
await page.mouse.move(100, 100)
await page.mouse.down()
await page.mouse.move(101, 101)
expect(await page.evaluate(() => __tldraw_editor_events.at(-1))).toMatchObject({
target: 'canvas',
type: 'pointer',
name: 'pointer_move',
})
})
test('pointer up', async () => {
await page.mouse.move(200, 200) // to kill any double clicks
await page.mouse.move(100, 100)
await page.mouse.down()
await page.mouse.move(101, 101)
await page.mouse.up()
Input buffering (#3223) This PR buffs input events. ## The story so far In the olde days, we throttled events from the canvas events hook so that a pointer event would only be sent every 1/60th of a second. This was fine but made drawing on the iPad / 120FPS displays a little sad. Then we removed this throttle. It seemed fine! Drawing at 120FPS was great. We improved some rendering speeds and tightened some loops so that the engine could keep up with 2x the number of points in a line. Then we started noticing that iPads and other screens could start choking on events as it received new inputs and tried to process and render inputs while still recovering from a previous dropped frame. Even worse, on iPad the work of rendering at 120FPS was causing the browser to throttle the app after some sustained drawing. Yikes! ### Batching I did an experimental PR (#3180) to bring back batching but do it in the editor instead. What we would do is: rather than immediately processing an event when we get it, we would instead put the event into a buffer. On the next 60FPS tick, we would flush the buffer and process all of the events. We'd have them all in the same transaction so that the app would only render once. ### Render batching? We then tried batching the renders, so that the app would only ever render once per (next) frame. This added a bunch of complexity around events that needed to happen synchronously, such as writing text in a text field. Some inputs could "lag" in a way familiar to anyone who's tried to update an input's state asynchronously. So we backed out of this. ### Coalescing? Another idea from @ds300 was to "coalesce" the events. This would be useful because, while some interactions like drawing would require the in-between frames in order to avoid data loss, most interactions (like resizing) didn't actually need the in-between frames, they could just use the last input of a given type. Coalescing turned out to be trickier than we thought, though. 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), and so the coalesced events would need to also include this information or else the handlers wouldn't work the way they should when processing the "final" event during a tick. So we backed out of the coalescing strategy for now. Here's the [PR that removes](https://github.com/tldraw/tldraw/pull/3223/commits/937469d69d4474fe9d1ff98604acb8f55a49f3fa) it. ### Let's just buffer the fuckers So this PR now should only include input buffering. I think there are ways to achieve the same coalescing-like results through the state nodes, which could gather information during the `onPointerMove` handler and then actually make changes during the `onTick` handler, so that the changes are only done as many time as necessary. This should help with e.g. resizing lots of shapes at once. But first let's land the buffering! --- Mitja's original text: This PR builds on top of Steve's [experiment PR](https://github.com/tldraw/tldraw/pull/3180) here. It also adds event coalescing for [`pointerMove` events](https://github.com/tldraw/tldraw/blob/mitja/input-buffering/packages/editor/src/lib/editor/Editor.ts#L8364-L8368). The API is [somewhat similar ](https://developer.mozilla.org/en-US/docs/Web/API/PointerEvent/getCoalescedEvents) to `getCoalescedEvent`. In `StateNodes` we register an `onPointerMove` handler. When the event happens it gets called with the event `info`. There's now an additional field on `TLMovePointerEvent` called `coalescedInfo` which includes all the events. It's then on the user to process all of these. I decided on this API since it allows us to only expose one event handler, but it still gives the users access to all events if they need them. We would otherwise either need to: - Expose two events (coalesced and non-coalesced one and complicate the api) so that state nodes like Resizing would not be triggered for each pointer move. - Offer some methods on the editor that would allow use to get the coalesced information. Then the nodes that need that info could request it. I [tried this](https://github.com/tldraw/tldraw/pull/3223/commits/9ad973da3aa287e7974067ac923193530d29c188#diff-32f1de9a5a9ec72aa49a8d18a237fbfff301610f4689a4af6b37f47af435aafcR67), but it didn't feel good. This also complicated the editor inputs. The events need to store information about the event (like the mouse position when the event happened for `onPointerMove`). But we cannot immediately update inputs when the event happens. To make this work for `pointerMove` events I've added `pagePoint`. It's [calculated](https://github.com/tldraw/tldraw/pull/3223/files#diff-980beb0aa0ee9aa6d1cd386cef3dc05a500c030638ffb58d45fd11b79126103fR71) when the event triggers and then consumers can get it straight from the event (like [Drawing](https://github.com/tldraw/tldraw/pull/3223/files#diff-32f1de9a5a9ec72aa49a8d18a237fbfff301610f4689a4af6b37f47af435aafcR104)). ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [x] `sdk` — Changes the tldraw SDK - [ ] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Add a step-by-step description of how to test your PR here. 4. - [ ] Unit Tests - [ ] End to end tests ### Release Notes - Add a brief release note for your PR here. --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-02 14:29:14 +00:00
await page.waitForTimeout(20)
expect(await page.evaluate(() => __tldraw_editor_events.at(-1))).toMatchObject({
target: 'canvas',
type: 'pointer',
name: 'pointer_up',
})
})
})
test.describe('click events', () => {
// todo
})
test.describe('pinch events', () => {
// todo
})
test.describe('keyboard events', () => {
// todo
})
test.fixme('wheel events', async () => {
await page.mouse.move(200, 200) // to kill any double clicks
await page.mouse.move(100, 100)
await page.mouse.wheel(10, 10)
expect(await page.evaluate(() => __tldraw_editor_events.at(-1))).toMatchObject({
type: 'wheel',
name: 'wheel',
delta: {
x: -20,
y: -20,
},
})
})
test.fixme('complete', async () => {
await page.evaluate(async () => editor.complete())
expect(await page.evaluate(() => __tldraw_editor_events.at(-1))).toMatchObject({
type: 'misc',
name: 'complete',
})
})
test.fixme('cancel', async () => {
await page.evaluate(async () => editor.cancel())
expect(await page.evaluate(() => __tldraw_editor_events.at(-1))).toMatchObject({
type: 'misc',
name: 'complete',
})
})
test.fixme('interrupt', async () => {
await page.evaluate(async () => editor.interrupt())
expect(await page.evaluate(() => __tldraw_editor_events.at(-1))).toMatchObject({
type: 'misc',
name: 'interrupt',
})
})
})
test.describe('Shape events', () => {
test.beforeEach(async ({ browser }) => {
page = await browser.newPage()
await setupPage(page)
await page.keyboard.press('r')
await page.mouse.click(150, 150)
await page.mouse.move(0, 0)
await page.keyboard.press('Escape')
})
test('pointer down', async () => {
await page.mouse.move(51, 51)
await page.mouse.down()
Input buffering (#3223) This PR buffs input events. ## The story so far In the olde days, we throttled events from the canvas events hook so that a pointer event would only be sent every 1/60th of a second. This was fine but made drawing on the iPad / 120FPS displays a little sad. Then we removed this throttle. It seemed fine! Drawing at 120FPS was great. We improved some rendering speeds and tightened some loops so that the engine could keep up with 2x the number of points in a line. Then we started noticing that iPads and other screens could start choking on events as it received new inputs and tried to process and render inputs while still recovering from a previous dropped frame. Even worse, on iPad the work of rendering at 120FPS was causing the browser to throttle the app after some sustained drawing. Yikes! ### Batching I did an experimental PR (#3180) to bring back batching but do it in the editor instead. What we would do is: rather than immediately processing an event when we get it, we would instead put the event into a buffer. On the next 60FPS tick, we would flush the buffer and process all of the events. We'd have them all in the same transaction so that the app would only render once. ### Render batching? We then tried batching the renders, so that the app would only ever render once per (next) frame. This added a bunch of complexity around events that needed to happen synchronously, such as writing text in a text field. Some inputs could "lag" in a way familiar to anyone who's tried to update an input's state asynchronously. So we backed out of this. ### Coalescing? Another idea from @ds300 was to "coalesce" the events. This would be useful because, while some interactions like drawing would require the in-between frames in order to avoid data loss, most interactions (like resizing) didn't actually need the in-between frames, they could just use the last input of a given type. Coalescing turned out to be trickier than we thought, though. 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), and so the coalesced events would need to also include this information or else the handlers wouldn't work the way they should when processing the "final" event during a tick. So we backed out of the coalescing strategy for now. Here's the [PR that removes](https://github.com/tldraw/tldraw/pull/3223/commits/937469d69d4474fe9d1ff98604acb8f55a49f3fa) it. ### Let's just buffer the fuckers So this PR now should only include input buffering. I think there are ways to achieve the same coalescing-like results through the state nodes, which could gather information during the `onPointerMove` handler and then actually make changes during the `onTick` handler, so that the changes are only done as many time as necessary. This should help with e.g. resizing lots of shapes at once. But first let's land the buffering! --- Mitja's original text: This PR builds on top of Steve's [experiment PR](https://github.com/tldraw/tldraw/pull/3180) here. It also adds event coalescing for [`pointerMove` events](https://github.com/tldraw/tldraw/blob/mitja/input-buffering/packages/editor/src/lib/editor/Editor.ts#L8364-L8368). The API is [somewhat similar ](https://developer.mozilla.org/en-US/docs/Web/API/PointerEvent/getCoalescedEvents) to `getCoalescedEvent`. In `StateNodes` we register an `onPointerMove` handler. When the event happens it gets called with the event `info`. There's now an additional field on `TLMovePointerEvent` called `coalescedInfo` which includes all the events. It's then on the user to process all of these. I decided on this API since it allows us to only expose one event handler, but it still gives the users access to all events if they need them. We would otherwise either need to: - Expose two events (coalesced and non-coalesced one and complicate the api) so that state nodes like Resizing would not be triggered for each pointer move. - Offer some methods on the editor that would allow use to get the coalesced information. Then the nodes that need that info could request it. I [tried this](https://github.com/tldraw/tldraw/pull/3223/commits/9ad973da3aa287e7974067ac923193530d29c188#diff-32f1de9a5a9ec72aa49a8d18a237fbfff301610f4689a4af6b37f47af435aafcR67), but it didn't feel good. This also complicated the editor inputs. The events need to store information about the event (like the mouse position when the event happened for `onPointerMove`). But we cannot immediately update inputs when the event happens. To make this work for `pointerMove` events I've added `pagePoint`. It's [calculated](https://github.com/tldraw/tldraw/pull/3223/files#diff-980beb0aa0ee9aa6d1cd386cef3dc05a500c030638ffb58d45fd11b79126103fR71) when the event triggers and then consumers can get it straight from the event (like [Drawing](https://github.com/tldraw/tldraw/pull/3223/files#diff-32f1de9a5a9ec72aa49a8d18a237fbfff301610f4689a4af6b37f47af435aafcR104)). ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [x] `sdk` — Changes the tldraw SDK - [ ] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Add a step-by-step description of how to test your PR here. 4. - [ ] Unit Tests - [ ] End to end tests ### Release Notes - Add a brief release note for your PR here. --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-02 14:29:14 +00:00
await page.waitForTimeout(20)
expect(await page.evaluate(() => __tldraw_editor_events.at(-1))).toMatchObject({
target: 'canvas',
type: 'pointer',
name: 'pointer_down',
})
})
test('pointer move', async () => {
await page.mouse.move(51, 51)
await page.mouse.move(52, 52)
Input buffering (#3223) This PR buffs input events. ## The story so far In the olde days, we throttled events from the canvas events hook so that a pointer event would only be sent every 1/60th of a second. This was fine but made drawing on the iPad / 120FPS displays a little sad. Then we removed this throttle. It seemed fine! Drawing at 120FPS was great. We improved some rendering speeds and tightened some loops so that the engine could keep up with 2x the number of points in a line. Then we started noticing that iPads and other screens could start choking on events as it received new inputs and tried to process and render inputs while still recovering from a previous dropped frame. Even worse, on iPad the work of rendering at 120FPS was causing the browser to throttle the app after some sustained drawing. Yikes! ### Batching I did an experimental PR (#3180) to bring back batching but do it in the editor instead. What we would do is: rather than immediately processing an event when we get it, we would instead put the event into a buffer. On the next 60FPS tick, we would flush the buffer and process all of the events. We'd have them all in the same transaction so that the app would only render once. ### Render batching? We then tried batching the renders, so that the app would only ever render once per (next) frame. This added a bunch of complexity around events that needed to happen synchronously, such as writing text in a text field. Some inputs could "lag" in a way familiar to anyone who's tried to update an input's state asynchronously. So we backed out of this. ### Coalescing? Another idea from @ds300 was to "coalesce" the events. This would be useful because, while some interactions like drawing would require the in-between frames in order to avoid data loss, most interactions (like resizing) didn't actually need the in-between frames, they could just use the last input of a given type. Coalescing turned out to be trickier than we thought, though. 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), and so the coalesced events would need to also include this information or else the handlers wouldn't work the way they should when processing the "final" event during a tick. So we backed out of the coalescing strategy for now. Here's the [PR that removes](https://github.com/tldraw/tldraw/pull/3223/commits/937469d69d4474fe9d1ff98604acb8f55a49f3fa) it. ### Let's just buffer the fuckers So this PR now should only include input buffering. I think there are ways to achieve the same coalescing-like results through the state nodes, which could gather information during the `onPointerMove` handler and then actually make changes during the `onTick` handler, so that the changes are only done as many time as necessary. This should help with e.g. resizing lots of shapes at once. But first let's land the buffering! --- Mitja's original text: This PR builds on top of Steve's [experiment PR](https://github.com/tldraw/tldraw/pull/3180) here. It also adds event coalescing for [`pointerMove` events](https://github.com/tldraw/tldraw/blob/mitja/input-buffering/packages/editor/src/lib/editor/Editor.ts#L8364-L8368). The API is [somewhat similar ](https://developer.mozilla.org/en-US/docs/Web/API/PointerEvent/getCoalescedEvents) to `getCoalescedEvent`. In `StateNodes` we register an `onPointerMove` handler. When the event happens it gets called with the event `info`. There's now an additional field on `TLMovePointerEvent` called `coalescedInfo` which includes all the events. It's then on the user to process all of these. I decided on this API since it allows us to only expose one event handler, but it still gives the users access to all events if they need them. We would otherwise either need to: - Expose two events (coalesced and non-coalesced one and complicate the api) so that state nodes like Resizing would not be triggered for each pointer move. - Offer some methods on the editor that would allow use to get the coalesced information. Then the nodes that need that info could request it. I [tried this](https://github.com/tldraw/tldraw/pull/3223/commits/9ad973da3aa287e7974067ac923193530d29c188#diff-32f1de9a5a9ec72aa49a8d18a237fbfff301610f4689a4af6b37f47af435aafcR67), but it didn't feel good. This also complicated the editor inputs. The events need to store information about the event (like the mouse position when the event happened for `onPointerMove`). But we cannot immediately update inputs when the event happens. To make this work for `pointerMove` events I've added `pagePoint`. It's [calculated](https://github.com/tldraw/tldraw/pull/3223/files#diff-980beb0aa0ee9aa6d1cd386cef3dc05a500c030638ffb58d45fd11b79126103fR71) when the event triggers and then consumers can get it straight from the event (like [Drawing](https://github.com/tldraw/tldraw/pull/3223/files#diff-32f1de9a5a9ec72aa49a8d18a237fbfff301610f4689a4af6b37f47af435aafcR104)). ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [x] `sdk` — Changes the tldraw SDK - [ ] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Add a step-by-step description of how to test your PR here. 4. - [ ] Unit Tests - [ ] End to end tests ### Release Notes - Add a brief release note for your PR here. --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-02 14:29:14 +00:00
await page.waitForTimeout(20)
expect(await page.evaluate(() => __tldraw_editor_events.at(-1))).toMatchObject({
target: 'canvas',
type: 'pointer',
name: 'pointer_move',
})
})
test('pointer up', async () => {
await page.mouse.move(51, 51)
await page.mouse.down()
await page.mouse.up()
Input buffering (#3223) This PR buffs input events. ## The story so far In the olde days, we throttled events from the canvas events hook so that a pointer event would only be sent every 1/60th of a second. This was fine but made drawing on the iPad / 120FPS displays a little sad. Then we removed this throttle. It seemed fine! Drawing at 120FPS was great. We improved some rendering speeds and tightened some loops so that the engine could keep up with 2x the number of points in a line. Then we started noticing that iPads and other screens could start choking on events as it received new inputs and tried to process and render inputs while still recovering from a previous dropped frame. Even worse, on iPad the work of rendering at 120FPS was causing the browser to throttle the app after some sustained drawing. Yikes! ### Batching I did an experimental PR (#3180) to bring back batching but do it in the editor instead. What we would do is: rather than immediately processing an event when we get it, we would instead put the event into a buffer. On the next 60FPS tick, we would flush the buffer and process all of the events. We'd have them all in the same transaction so that the app would only render once. ### Render batching? We then tried batching the renders, so that the app would only ever render once per (next) frame. This added a bunch of complexity around events that needed to happen synchronously, such as writing text in a text field. Some inputs could "lag" in a way familiar to anyone who's tried to update an input's state asynchronously. So we backed out of this. ### Coalescing? Another idea from @ds300 was to "coalesce" the events. This would be useful because, while some interactions like drawing would require the in-between frames in order to avoid data loss, most interactions (like resizing) didn't actually need the in-between frames, they could just use the last input of a given type. Coalescing turned out to be trickier than we thought, though. 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), and so the coalesced events would need to also include this information or else the handlers wouldn't work the way they should when processing the "final" event during a tick. So we backed out of the coalescing strategy for now. Here's the [PR that removes](https://github.com/tldraw/tldraw/pull/3223/commits/937469d69d4474fe9d1ff98604acb8f55a49f3fa) it. ### Let's just buffer the fuckers So this PR now should only include input buffering. I think there are ways to achieve the same coalescing-like results through the state nodes, which could gather information during the `onPointerMove` handler and then actually make changes during the `onTick` handler, so that the changes are only done as many time as necessary. This should help with e.g. resizing lots of shapes at once. But first let's land the buffering! --- Mitja's original text: This PR builds on top of Steve's [experiment PR](https://github.com/tldraw/tldraw/pull/3180) here. It also adds event coalescing for [`pointerMove` events](https://github.com/tldraw/tldraw/blob/mitja/input-buffering/packages/editor/src/lib/editor/Editor.ts#L8364-L8368). The API is [somewhat similar ](https://developer.mozilla.org/en-US/docs/Web/API/PointerEvent/getCoalescedEvents) to `getCoalescedEvent`. In `StateNodes` we register an `onPointerMove` handler. When the event happens it gets called with the event `info`. There's now an additional field on `TLMovePointerEvent` called `coalescedInfo` which includes all the events. It's then on the user to process all of these. I decided on this API since it allows us to only expose one event handler, but it still gives the users access to all events if they need them. We would otherwise either need to: - Expose two events (coalesced and non-coalesced one and complicate the api) so that state nodes like Resizing would not be triggered for each pointer move. - Offer some methods on the editor that would allow use to get the coalesced information. Then the nodes that need that info could request it. I [tried this](https://github.com/tldraw/tldraw/pull/3223/commits/9ad973da3aa287e7974067ac923193530d29c188#diff-32f1de9a5a9ec72aa49a8d18a237fbfff301610f4689a4af6b37f47af435aafcR67), but it didn't feel good. This also complicated the editor inputs. The events need to store information about the event (like the mouse position when the event happened for `onPointerMove`). But we cannot immediately update inputs when the event happens. To make this work for `pointerMove` events I've added `pagePoint`. It's [calculated](https://github.com/tldraw/tldraw/pull/3223/files#diff-980beb0aa0ee9aa6d1cd386cef3dc05a500c030638ffb58d45fd11b79126103fR71) when the event triggers and then consumers can get it straight from the event (like [Drawing](https://github.com/tldraw/tldraw/pull/3223/files#diff-32f1de9a5a9ec72aa49a8d18a237fbfff301610f4689a4af6b37f47af435aafcR104)). ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [x] `sdk` — Changes the tldraw SDK - [ ] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. Add a step-by-step description of how to test your PR here. 4. - [ ] Unit Tests - [ ] End to end tests ### Release Notes - Add a brief release note for your PR here. --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-02 14:29:14 +00:00
await page.waitForTimeout(20)
expect(await page.evaluate(() => __tldraw_editor_events.at(-1))).toMatchObject({
target: 'canvas',
type: 'pointer',
name: 'pointer_up',
})
})
})