Triple Buffering
Three render-state slots help separate producer and consumer updates.
Availability
Implemented in the stable source; configuration and compatibility limits are described below.
Reviewed against stable v0.5.1. Rust candidate additions are labeled separately. Release status.
The pain this solves
- Render-state production and consumption can contend over mutable state.
- Metal drawables and application state buffers are easy to conflate.
What ships with it
- Stable code rotates three render-state buffers with atomic indices.
- The Metal layer separately allows three drawables.
- This does not establish zero contention or fixed latency.
Questions this answers
- What does Chau7 triple-buffer?
- Are render-state buffers and Metal drawables the same mechanism?
- Does triple buffering guarantee zero contention?
How it works
The stable TripleBuffering implementation allocates three state buffers and rotates published, ready, and reading indices using atomic operations.
Separately, the Metal view configures its layer with a maximum drawable count of three. Application render-state buffers and Metal drawables are distinct mechanisms.
Triple buffering can reduce coordination stalls in this handoff design. The source does not prove zero contention, zero copying, a fixed frame rate, or a universal latency bound.
Why it matters
A three-slot handoff gives the renderer room to publish state while another part of the app reads a prior state. That implementation detail is not a promise about observed speed.
Frequently asked questions
What does Chau7 triple-buffer?
The stable source has a three-buffer render-state exchange and separately configures the Metal drawable layer for three drawables.
Does triple buffering eliminate all contention?
No. It is a coordination strategy, not proof of a contention-free system.