PlaybackStats

Diagnostics, for an overlay or a bug report.

The counters here are monotonic totals, not per-interval values, and that is deliberate. A consumer that wants a rate diffs two snapshots. Publishing occurrences as events instead would be wrong: a state feed coalesces by design, so an event stream of "a frame was dropped" is exactly the kind of thing that silently loses entries. libmpv learned this the hard way and had to add three logical timestamps per observer to compensate.

Scheduler counters, not renderer counters

Every frame figure here is a decision the engine's schedule made or an outcome it can see with its own eyes: submittedFrames means a renderer accepted the frame, headlessFrames means there was no renderer to accept it, and droppedFramesLate and repeatedFrames are the schedule's own choices about pacing. None of them says that a pixel reached a display.

What was drawn is the renderer's own count, and it is deliberately not mirrored here. A renderer that takes a frame may still supersede it with a newer one or fail to draw it, and it counts those outcomes itself: the Core Graphics renderer in kiteplayer-output publishes presentedFrames, supersededFrames and failedFrames, whose sum is what the engine submitted to it. Read the pair of numbers side by side: submitted against drawn is the difference between the engine keeping up and the output keeping up, and copying the second group into this class would only invent a figure the engine cannot know, because no member of the renderer interface reports one. Per-submission terminal feedback is the tracked work that would change that.