Define a small renderer application using explicit owners, borrowed interfaces, validated work, and meaningful failure boundaries.
This chapter’s project
An ownership diagram, a bounded work API, and tests for rejected and failed work.
A softer light for long learning sessions.
Loading your preference…
Light uses Latte. Your choices stay in this browser.
Volume 04 · 16 flexible weeks
Keep the picture alive under pressure.
Give a renderer dependable boundaries: bounded work, ownership, cancellation, asset generations, allocation budgets, profiling, and reproducible releases.
Open my weekly workbench ↗Load and replace assets without stale results or unbounded queues, and explain shutdown and failure paths.
Your sketchbook / 8 chapters
Two weeks per chapter: understand and build, then investigate and finish. Repeat any week.
Define a small renderer application using explicit owners, borrowed interfaces, validated work, and meaningful failure boundaries.
An ownership diagram, a bounded work API, and tests for rejected and failed work.
Use PMR only where its allocation and reset contracts are visible, and keep worker lifetimes inside scratch lifetimes.
A PMR lifetime diagram, exhaustion test, and promoted result that survives reset.
Run bounded owned jobs with std::jthread, cooperative cancellation, deterministic synchronization tests, and explicit joining.
A bounded worker experiment with cancellation ordering, failure outcomes, and a shutdown diagram.
Model asset preparation and publication with generations, explicit states, owning results, and stable prior assets on failure.
An original state diagram, a stale-completion regression, and a failure-preserves-current test.
Distinguish future completion, cooperative stop, coroutine syntax, scheduler behavior, and awaitable lifetime without building an unsafe runtime.
A runnable timer success/cancel/failure trace, a frame-lifetime check, and a CP.51–53 review.
Design a backend-neutral resource-retirement model while clearly distinguishing it from real API synchronization.
A two-timeline diagram, a bounded retirement policy, and a clearly labeled pure state-model test.
Build reproducible correctness and performance evidence without conflating throughput, latency, memory, and device timing.
A measurement protocol, repeated results, a correctness check, and an explained tradeoff.
Release an original bounded gallery subset with ownership, shutdown, failure, measurement, and contribution evidence.
A reproducible application subset, owner/shutdown diagrams, failure tests, one measurement, and a contribution statement.
Keep your hands on the work
The companion explains its build steps, tested behavior, and remaining learner work. Keep your own contribution clear as the project grows.