perf(ios): anchor recording gesture clock from runner response stamps#762
Merged
Conversation
Every ok runner response now carries a transport-stamped currentUptimeMs captured just before the HTTP write. Simulator recording start anchors gesture overlay timing from the warm snapshot response it already makes, skipping the standalone uptime request. The standalone uptime path stays as fallback for older runner builds, and journal-stored responses remain unstamped so recovered results never pair a stale uptime with a late receipt time. Closes #670
Size Report
Startup median (7 runs, lower is better):
Top changed chunks:
|
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #670
What
Starting an iOS simulator recording with touch overlays no longer sends a standalone
uptimerunner command just to anchor gesture-overlay timing.currentUptimeMs(the same monotonic clock used forgestureStart/EndUptimeMstelemetry) onto every ok response at the single transport encoding chokepoint, captured just before the HTTP write.snapshotresponse it already makes:gestureClockOriginUptimeMs= the stamped value,gestureClockOriginAtMs= daemon receipt time. Receipt-time pairing is used instead of request midpoint because the warm request can include cold runner launch (10s+); the late bias is one-way loopback latency (single-digit ms), far below overlay tolerance (tap markers render for ≥450ms).commandJournal.finish, so journal-storedlifecycleResponseJsonstays unstamped — a journal-recovered response never pairs a stale uptime with a late receipt time; the daemon just falls back.Fallback
If the anchor is missing or unusable (older cached runner build, warm-up failure, non-finite value), the existing standalone
uptime+ request-midpoint pairing runs unchanged; if that also fails, the existing wall-clock-only degradation remains. The iOS physical-device and macOS recording flows are untouched.Validation (iPhone 17 Pro Max simulator, iOS 26.2)
Per-request diagnostics (
--debug) forrecord startwith touch overlays:snapshot+uptimesnapshotonlyThe branch run emits a
record_start_gesture_clock_anchordiagnostic confirming the anchor came from the warm response. Recorded a tap with overlays on both main and this branch: the marker appears at the tap moment and fades identically on both (frame-by-frame comparison), so overlay timing is preserved. (Both branches show a pre-existing marker y-position offset, tracked separately.)pnpm typecheckpasses; record-trace, record-trace-ios, and recording-timing suites pass (46 tests).pnpm build:xcuitest:iossucceeds; new Swift XCTest cases cover the stamping helper and assert journal responses stay unstamped.