Invert the draw transform
In this fixture path, Android draws a centered, optionally rotated and scaled 320 × 480 guest canvas. GuestCoordinates reverses that transform. It first removes the host center, divides by the selected scale, applies the inverse rotation, and restores the guest center. [input], [view]
unrotated: gx = (hostX − hostWidth/2) / scale + 160 gy = (hostY − hostHeight/2) / scale + 240 clockwise presentation, inverse input mapping: gx = dy + 160 gy = −dx + 240
Fit takes the smaller scale and can leave bars. Fill takes the larger scale and can crop guest content. In both modes the displayed transform and input transform must agree. The colored marker uses the calculation rather than a prerecorded animation.
Hit testing and active-contact mapping differ
The initial down event must land inside both the Android view and visible guest coordinates. Once tracking begins, the contact may leave the guest rectangle. The mapContact helper allows a bounded extended coordinate range and floors coordinates; the initial map helper returns a point only within the guest. Treating both cases as an identical bounds check can prematurely end a drag. [input]
The inspected stream handles one contact. Extra pointer down/up and cancellation terminate tracking; ordinary down, move, and up map to explicit phases. A terminal event is important even when the pointer ends outside the original target. Touchscreen multitouch support is not implied by the existence of a MotionEvent handler. [view]
The queue preserves transitions, not every sample
GuestTouchQueue reserves capacity for terminal events and coalesces only adjacent moves belonging to the same active contact. It checks identity, phase, coordinate bounds, and nondecreasing time. Dropping an old move can be acceptable; silently dropping the release can leave the guest in an interaction that never ends. [input]
The wire command carries sequence, contact, phase, coordinates, and elapsed milliseconds. Its time is contact-stream time, not a synchronized cross-machine clock. Sending a command is not evidence that UIKit dispatched it, and dispatching it is not evidence that a frame was displayed.
DBTOUCH sequence contact phase x y milliseconds phase: 0 down · 1 move · 2 up · 3 cancel
Latency includes pacing and recovery
The socket loop has paced and burst modes. In paced mode it attempts one output byte per 30 ms interval; scheduling may make it slower. A command of N bytes therefore needs at least approximately (N−1) × 30 ms between first and last byte under ideal pacing. That is a code-derived lower bound for this mode, not a measured end-to-end latency. [view]
Why not always burst? The research notes trace a failure where long acknowledgements lost exactly 16 leading bytes. The inspected UART ring used equal indices for empty while allowing all slots to fill. A later hash-pinned candidate reserved one slot; the paired experiment then delivered intact ACKs and completed the controlled recovery run. That is a specific A/B result, not a general proof about every UART path or device. [blueberry]
A complete latency trace would separate host touch, queue entry, wire send, guest receive, UI dispatch, state mutation, frame export, host acceptance, and presentation. Report durations between well-defined points. A capture time, queue delay, and input round-trip cannot be interchanged.
A closed-loop playground needs an observable result
The existing Swift playground compiles a module on the Mac, pushes a shared library through ADB, and changes a current-file marker that the Android app polls. A polished UI can expose these stages, but must also detect module loading and the resulting rendered state. A successful adb push alone closes neither the execution loop nor the interaction loop. [playground]
For a counter, a useful test starts from a known value, observes the rendered value, injects one supported action, then verifies the next value and matching render revision. It should preserve compiler diagnostics, selected target, module hash, input event, and captured output. Swift source through ShimKit and an iOS guest app need separately named run targets.
The Daybreak Terminal proposal extends this idea to services. Share, clipboard, persistence, lifecycle, and networking need individual contracts and evidence, rather than one green “iOS works” indicator.
References and evidence
Implementation references describe a working-tree snapshot. They are not all present in a public repository. The source inventory records file hashes; historical notes are not new device tests.
- [input] Daybreak, GuestCoordinates.kt / GuestTouchQueue.kt. Inspected working tree, 2026-09-10; same Android directory. Coordinate inversion, contact lifetime and move coalescing. Private workspace source; collaborator access required.
- [view] Daybreak, GuestFrameActivity.kt / GuestSocketClient.kt. Inspected working tree, 2026-09-10; same Android directory. UI scheduling, Canvas operations, reliable/unframed selection, paced input. Private workspace source; collaborator access required.
- [blueberry] Daybreak, BlueBerry Guest Frame Presentation. docs/research/blueberry-guest-frame-presentation.md. Read through the later UART failure and patched-candidate A/B result; opening snapshot checkpoint is not the whole history. Private workspace source; collaborator access required.
- [playground] Daybreak, tools/playground.sh and Swift playground source. Inspected working tree, 2026-09-10. Mac compilation, ADB library delivery and polled current-file selection. Private workspace source; collaborator access required.