screenLoad

A fill that changes what the screen says. The default.

An image / texture load. Passed explicitly.

begin: open a ledger for one load of this component. Restarts any ledger already open — a re-load (a refresh, a second item opened without leaving the screen) is a new run, not a continuation of the last one.

NOT an entry in tests/rta/screens.js: one component serves many screens there (itemDetails backs all nine *Details entries), and the app has no way to know which of them the operator navigated to. The RTA screen name is established by --nav DRIVING there, and measure.js records the two separately for exactly that reason — conflating them under one word screen is what let a movieDetails series and a seriesDetails series compare as one population.

The build flags the sample was taken under, stamped by the app itself so a number can never be silently compared against one measured in a distorting build — a debug=true build attaches rawApiData to every transformed item. Provenance belongs in the sample, not in someone's memory of which manifest was checked out.

ENABLE_RTA is deliberately NOT here: it is the third flag that can move a measurement (it makes the on-device ODC component resident) and the app cannot self-report it usefully — scripts/measure.js derives it from the deploy it performed. See the note in scripts/measurements.js.

cancel: withdraw a declared fill that turned out not to start, WITHOUT recording it.

Exists so a caller can declare a fill BEFORE the call that may or may not begin it, which is the only ordering that is safe when the resolve could in principle land synchronously inside that call. ItemDetails' logo is the case: a Poster only loads when its uri actually changes, and whether it changed is knowable only after setItemLogo returns — but if a warm texture cache could deliver loadStatus synchronously during the assignment, declaring afterwards would let the resolve outrun its own pending and strand the screen unsettled forever.

Roku documents loadStatus as a fetch-and-decode progression and says nothing about whether a same-thread observer is delivered synchronously, so rather than assert an answer, declare-then-cancel makes the ordering correct under BOTH. A cancelled fill is not a zero-millisecond fill: it never happened, so it must not inflate the fill count or the class totals.

paint: the screen has rendered. Emits the paint line.

Stop the clock at the END of the handler that renders the content — the moment all render work is submitted and the loading spinner comes down. That is "content ready", not time-to-photons; the frame itself lands a beat later. The honest alternative is the first renderTracking callback, which is closer to what the eye sees but fires repeatedly and needs a per-screen rule for which fire counts — which is exactly the per-screen knowledge this ledger exists to remove.

serves several: the item type for ItemDetails, the library type for a grid. It is what lets a sample be attributed rather than guessed at by position — a chained navigation mounts ItemDetails more than once per launch (a Season is reached THROUGH its Series), so "the first sample in the window" is not the one asked for.

pending: declare one outstanding async fill. See rule 1 in the header — declare every fill before calling paint.

It is what the settled line names as the slowest, so it should say what was being waited on rather than which task ran.

resolve: one declared fill has landed. When the last one lands on a painted screen, the settled line is emitted.

A resolve with no matching pending on an OPEN run is reported: it means the two sides have drifted, and an unbalanced ledger publishes a settled time describing a different set of fills than the reader will assume.

After settle, though, it is silent — mirroring pending. The run is over, and the resolves that arrive next belong to work nobody opened a ledger for: a return from playback re-runs the trailer check, the refresh button re-runs the extras chain, and a Season re-sets its logo when the first one never became visible. All three are ordinary user actions, all three happen in every perfTiming build, and warning on them would fire the drift alarm routinely — which trains the reader to ignore the one signal that is supposed to mean something is genuinely wrong.

Emit the settled pair once every declared fill has resolved on a painted screen.

Emits at most once per run. A fill that lands after the last one — a straggler from a cancelled chain, a second callback on one task — must not publish a second, later settled time for the same load: two lines that disagree, with nothing on the wire to say which one the reader meant.

The open ledger, or invalid. The one supported way to READ the state.

Exists because "the caller's m" is not the same m everywhere, and the difference is invisible until something reads back what it wrote. A plain function in a component's scope — every call site in ItemDetails — shares its m with the namespaced functions it calls, which is what makes the ledger work at all. A BrighterScript CLASS method does not: its m is the class instance, while a global function it calls sees the enclosing scope's m, so a class that instrumented itself would write one ledger and read another and never notice.

Reaching through this accessor is correct under both, because it resolves m exactly where the writes did. Callers should not poke at m.screenLoad directly; the suite in tests/source/unit/utils/screenReadiness.spec.bs found this the hard way.

The wire must never carry an empty token where a name belongs: a line reading variant ms 812 collapses two spaces and shifts every field after it, so the pattern would either fail to match or match the wrong group. none is a value; an empty string is a hole.