The problem
The pipeline is fully instrumented and the numbers are split across two machines that do not share a clock:
- Mac: queue wait, encode, send completion, round trip
- Receiver: hand-off from the socket to the WebView, decode, paint, present
Answering where do the milliseconds go means reading two places and adding up numbers that were measured differently. Nobody does that mid-session, which is when it matters.
Why it is not trivial
There is no shared clock, and the project has been careful not to pretend otherwise. Every stage is deliberately measured between two stamps on one machine — that is what makes the numbers trustworthy, and it is exactly what stops them being concatenated.
The one honest bridge is the round trip the Mac already measures from the receiver's echo, which is a true round trip against a single clock.
So the target is not a single timeline. It is: each machine's chain, side by side, with the network's share between them, and no arithmetic that quietly implies more precision than exists.
Suggested shape
The receiver already reports decodeMillis, decodedFrames, droppedFrames and queuedFrames in its stats message, so the control channel for this exists. Adding hand-off, paint and present is a small extension — but note the wire format is spec'd with golden vectors and the control channel is JSON and deliberately extensible, which is the right place for this. Do not add fields to the binary header.
Then either end can show the whole picture. The receiver's HUD is the natural home, since that is where someone is looking when it feels slow.
Care needed
- Say what is unmeasured. The gap between the two chains includes the network and anything neither side can see. Presenting it as a single total invites a precision that is not there.
- A stage with no samples is not a stage that costs nothing.
stageRow already refuses to print 0.0 ms for an unmeasured stage, for exactly this reason.
- Do not add per-frame traffic to the control channel. The hand-off measurement samples one frame in fifteen precisely so measuring stays free.
The problem
The pipeline is fully instrumented and the numbers are split across two machines that do not share a clock:
Answering where do the milliseconds go means reading two places and adding up numbers that were measured differently. Nobody does that mid-session, which is when it matters.
Why it is not trivial
There is no shared clock, and the project has been careful not to pretend otherwise. Every stage is deliberately measured between two stamps on one machine — that is what makes the numbers trustworthy, and it is exactly what stops them being concatenated.
The one honest bridge is the round trip the Mac already measures from the receiver's echo, which is a true round trip against a single clock.
So the target is not a single timeline. It is: each machine's chain, side by side, with the network's share between them, and no arithmetic that quietly implies more precision than exists.
Suggested shape
The receiver already reports
decodeMillis,decodedFrames,droppedFramesandqueuedFramesin its stats message, so the control channel for this exists. Adding hand-off, paint and present is a small extension — but note the wire format is spec'd with golden vectors and the control channel is JSON and deliberately extensible, which is the right place for this. Do not add fields to the binary header.Then either end can show the whole picture. The receiver's HUD is the natural home, since that is where someone is looking when it feels slow.
Care needed
stageRowalready refuses to print0.0 msfor an unmeasured stage, for exactly this reason.