From dc93f1c1fd7b67e2da5af2ffada732b9ddeb2d6a Mon Sep 17 00:00:00 2001 From: Kent Daleng Date: Sun, 17 Aug 2025 16:05:41 +0200 Subject: github wiki replacement / mkdocs-docs (#2147) * Add wiki based on mkdocs * wording fixes * fix github bg color on narrow * Fix left sidebar section headers being bigger than pages * fix hover accent * fix list rendering on fractional layout * fix videos * fix automatic full links * remove redundant commented css * improve dark mode contrast * update pygments for better child node coloring * update logo * remove blank lines * add systemd language hint --------- Co-authored-by: Ivan Molodetskikh --- wiki/Development:-Redraw-Loop.md | 22 ---------------------- 1 file changed, 22 deletions(-) delete mode 100644 wiki/Development:-Redraw-Loop.md (limited to 'wiki/Development:-Redraw-Loop.md') diff --git a/wiki/Development:-Redraw-Loop.md b/wiki/Development:-Redraw-Loop.md deleted file mode 100644 index 7f3d1873..00000000 --- a/wiki/Development:-Redraw-Loop.md +++ /dev/null @@ -1,22 +0,0 @@ -On a TTY, only one frame can be submitted to an output at a time, and the compositor must wait until the output repaints (indicated by a VBlank) to be able to submit the next frame. -In niri we keep track of this via the `RedrawState` enum that you can find in an `OutputState`. - -Here's a diagram of state transitions for the `RedrawState` state machine: - - - - RedrawState state transition diagram - - -`Idle` is the default state, when the output does not need to be repainted. -Any operation that may cause the screen to update calls `queue_redraw()`, which moves the output to a `Queued` state. -Then, at the end of an event loop dispatch, niri calls `redraw()` for every `Queued` output. - -If the redraw causes damage (i.e. something on the output changed), we move into the `WaitingForVBlank` state, since we cannot redraw until we receive a VBlank event. -However, if there's no damage, we do not return to `Idle` right away. -Instead, we set a timer to fire roughly at when the next VBlank would occur, and transition to a `WaitingForEstimatedVBlank` state. - -This is necessary in order to throttle frame callbacks sent to applications to at most once per output refresh cycle. -Without this throttling, applications can start continuously redrawing without damage (for instance, if the application window is partially off-screen, and it is only the off-screen part that changes), and eating a lot of CPU in the process. - -Then, either the estimated VBlank timer completes, and we go back to `Idle`, or maybe we call `queue_redraw()` once more and try to redraw again. -- cgit