Module input_frame 

Where a key’s time goes inside the app, stage by stage.

With RUST_LOG enabling tilo::input_frame=debug (the launcher forwards RUST_LOG into the sandbox), each key press the window dispatches starts a record, and the first frame submitted after it ends one: one content-free INPUT-FRAME line on stderr, which the session log keeps beside the compositor’s KEY-LATENCY for the same key.

INPUT-FRAME keys=1 handle_us=180 wait_us=2100 frame_us=3400 ui.frame_sync=2900/1 ui.layout=300/1 ... present_us=900 total_us=6580

• handle_us: the window handling the key event;
• wait_us: from the event handled to the frame that answers it starting;
• frame_us: that frame, start to its scene handed to the render thread;
• then every named scope (tilo_resource::profiling::Phase) that ran from the key to that frame, as microseconds and calls: the framework’s sync, layout and draw, its publication, the app’s own; those that ran while the key was handled, before the frame, are marked key:. Scopes nest, so they do not add up;
• repaint: full with why (full:structure+presence), or the pixels the frame’s damage repaints (repaint_px), in how many rectangles, and the largest;
• present_us: the render thread rasterising and presenting it, which commits the surface;
• total_us: dispatch to present.

Delivery to the app is not here: a Wayland key’s timestamp has no defined base. The compositor’s KEY-LATENCY key-to-commit for the same key, less total_us, is the time from the compositor sending the key to the window dispatching it.

Keys that arrive before the frame starts join it (keys). Off, each call here is one thread-local flag read, and scopes read no clock.

Constants

TARGET

The tracing target that turns the record on.