joule-moq-web room: draw only what changed, and send a key at once #585

Merged

dcharlot merged 1 commit from room/draw-on-new-frame into main 2026-11-02 19:49:35 -05:00

Conversation 0 Commits 1 Files changed 7 +316 -15

dcharlot commented 2026-11-02 14:05:45 -05:00

Owner

Copy link

The room's compositor redrew every tile on a fixed timer whether or not a frame had arrived, on a canvas asking for software rendering so a test hook could read it back. A still room spent draws at the full rate, and a frame waited up to a whole period for the next tick.

What changes

• A tile is drawn when its video has a new frame, at the next display refresh, with whatever lies over it. The whole canvas is drawn only after a re-layout. Drawing the whole canvas on every new frame would be worse for a large grid, whose unsynchronised sources would repaint all of it at every refresh.
• The canvas no longer asks for software rendering.
• stats() reports what drawing spent. The counts are held by the test, because a busy host can't flake them (draws <= frames + relayouts + 1). The latency from a frame's arrival to its drawing is reported, not held.
• The log and timeline no longer grow without bound in the DOM: 2,000 and 1,000 lines.
• Remote control held every action for the next refresh. A key, a button or a wheel now goes at once, with the moves before it.
• A bug this fixes: coalesced pointer moves kept the pointer's oldest place in a refresh, because the batch held a copy of the move that later ones updated in vain. They now keep the latest.

Evidence

• Node tests: compose.test.mjs 9, remote_input.test.mjs 7, both run from e2e/run.sh.
• Mutations: 11 of 11 in the compositor and 5 of 5 in the input path caught.
• Real browser on the build host at load about 150: room 348 of 348 checks, conversations and calls 17 of 17.

Not measured: the frame latency this saves on a real display. The host above is shared and headless, so the figure would not mean much; the counts are what the test holds.

🤖 Generated with Claude Code

The room's compositor redrew every tile on a fixed timer whether or not a frame had arrived, on a canvas asking for software rendering so a test hook could read it back. A still room spent draws at the full rate, and a frame waited up to a whole period for the next tick. **What changes** - A tile is drawn when its video has a new frame, at the next display refresh, with whatever lies over it. The whole canvas is drawn only after a re-layout. Drawing the whole canvas on every new frame would be worse for a large grid, whose unsynchronised sources would repaint all of it at every refresh. - The canvas no longer asks for software rendering. - `stats()` reports what drawing spent. The counts are held by the test, because a busy host can't flake them (`draws <= frames + relayouts + 1`). The latency from a frame's arrival to its drawing is reported, not held. - The log and timeline no longer grow without bound in the DOM: 2,000 and 1,000 lines. - Remote control held every action for the next refresh. A key, a button or a wheel now goes at once, with the moves before it. - **A bug this fixes:** coalesced pointer moves kept the pointer's oldest place in a refresh, because the batch held a copy of the move that later ones updated in vain. They now keep the latest. **Evidence** - Node tests: `compose.test.mjs` 9, `remote_input.test.mjs` 7, both run from `e2e/run.sh`. - Mutations: 11 of 11 in the compositor and 5 of 5 in the input path caught. - Real browser on the build host at load about 150: room 348 of 348 checks, conversations and calls 17 of 17. **Not measured:** the frame latency this saves on a real display. The host above is shared and headless, so the figure would not mean much; the counts are what the test holds. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 1 commit 2026-11-02 14:05:45 -05:00

joule-moq-web room: draw only what changed, and send a key at once ... d3507ca658

The room's compositor redrew every tile on a fixed timer, whether or not a new
frame had arrived, on a canvas asking for software rendering so that a test hook
could read it back. A still room spent draws at the full rate, and a frame waited
up to a whole period for the next tick.

A tile is now drawn when its video has a new frame, at the next display refresh,
with whatever lies over it; the whole canvas only after a re-layout. Simply drawing
the canvas on every new frame would be worse for a large grid, whose unsynchronised
sources would repaint all of it at every refresh. `stats()` reports what drawing
spent: counts a test can hold, since a busy host can't flake them, and the latency
from a frame's arrival to its drawing, which is reported and not held.

The room's log and timeline no longer grow without bound in the DOM.

Remote control held every action for the next refresh. A pointer moving is many
actions a refresh, and that suits it; a key, a button or a wheel is one thing that
happened, and now goes at once with the moves before it. Coalesced moves also kept
the pointer's oldest place in a refresh, because the batch held a copy of the move
that later ones updated in vain. They now keep the latest.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot merged commit 6adb72f2e7 into main 2026-11-02 19:49:35 -05:00

dcharlot referenced this pull request from a commit 2026-11-02 19:49:36 -05:00

Merge pull request 'joule-moq-web room: draw only what changed, and send a key at once' (#585) from room/draw-on-new-frame into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

Transaction-Science/open-standards!585

No description provided.