pub struct PingPong { /* private fields */ }Expand description
Which of two cursor buffers is live.
Implementations§
Source§impl PingPong
impl PingPong
Sourcepub const fn single() -> Self
pub const fn single() -> Self
A single buffer, for the legacy path.
The legacy ioctls take one buffer handle and have no flip to alternate on, so a second buffer buys nothing there.
Sourcepub const fn draw_target(self) -> usize
pub const fn draw_target(self) -> usize
The buffer to draw the next frame into.
The one that is not on screen, so drawing cannot tear. With a single buffer there is no choice, and the tear is accepted: the legacy path redraws the buffer the CRTC is showing, which only a new shape or an animation frame does.
Sourcepub const fn commit_target(self) -> usize
pub const fn commit_target(self) -> usize
The buffer the next commit should publish.
Whatever was just drawn, if anything was. A commit that only moves the cursor re-publishes the buffer already on screen rather than flipping to a stale one.
Sourcepub const fn mark_drawn(&mut self)
pub const fn mark_drawn(&mut self)
Note that a frame has been drawn into PingPong::draw_target.
Sourcepub const fn has_undrawn(self) -> bool
pub const fn has_undrawn(self) -> bool
Whether a draw is waiting to reach the screen.
Sourcepub const fn published(&mut self)
pub const fn published(&mut self)
Note that a commit published PingPong::commit_target.
The buffer just published becomes the live one, so the next draw goes to the one now safely off screen.
Call this on a commit that landed. Where the caller owns the commit there is no way to know, and calling it optimistically is the right trade: if their commit failed, scanout is still reading the buffer this just marked as the draw target, and the next draw there can tear — which is exactly what a single buffer does all the time. A successful commit, the overwhelmingly common case, is tear-free.