Retained realtime UI

The game view
is a Control.

Cerneala already combines ordinary application UI and complete 2D game rendering in one retained tree. The work ahead is about making SDL3 GPU the primary backend, evolving Cerberus without breaking retained ownership, and turning a source-first framework into something other developers can adopt without archaeology.

Snapshot8/28/2026
Established arcs04
Active arcs02
Planned arcs02

This records direction and maturity, not a release calendar. A type existing is not the same as a realistic scenario being conformant.

Current trajectory

Keep the retained model. Replace the weak parts with evidence.

Established Active Planned
01
Established authoring

Typed .crn and tooling

The language, parser, semantic model, diagnostics, source generator, generated application paths, language server, Visual Studio integration, and preview infrastructure are integrated and tested.

source generationtyped UI treelanguage tools
02
Established runtime

Retained UI core

Typed state, logical and visual trees, Relay, invalidation, measure and arrange, retained drawing commands, input, focus, commands, resources, Aspect, Motion, Prism, diagnostics, and automation run under one root.

UIRootretained cachesrouted input
03
Integrated game surface

RenderSurface2D

The game view is a retained ContentControl. It supports continuous or on-demand scheduling, retained drawing work, normal UI composition, and the complete implemented 2D drawing command surface.

ContentControl2D game viewretained commands
04
Initial backend complete

SDL3 and SDL3 GPU

Native desktop hosting, input, an SDL3 GPU drawing backend, Prism execution, cross-platform native smokes, and WindowsDX differential and pixel-conformance coverage exist in the repository.

WindowsLinuxmacOS
05
Strategic direction

Make SDL3 GPU primary

Move repository defaults, samples, native behavior, drawing, and Prism toward SDL3. MonoGame remains available during the transition, but it will be discontinued gradually after compatibility and removal policy are documented.

SDL3 defaultbackend conformanceMonoGame transition
06
Invariant under pressure

Preserve retained frame behavior

Renderer changes must not steal ownership from the UI runtime. Unchanged elements keep their command reuse, batching preserves visible order, resources release deterministically, and backend disagreement is resolved against the semantic contract.

no-work framesresource lifetimevisual parity
0707
Planned renderer architecture

Cerberus V2

The checked-in plans cover the compiler and encoder core, frame scheduling and upload arenas, retained compiled packets and GPU geometry, and multi-texture material pages. Planned does not mean delivered.

state shadowretained geometrymulti-texture
0808
Adoption work

External developer experience

Package boundaries, versioning, project templates, backend defaults, installation and upgrade instructions, a maintained minimal sample, and a preview compatibility policy still need explicit decisions and verified implementation.

packagestemplatescompatibility
Current game architecture

RenderSurface2D is already part of the UI tree.

This is not a foreign engine window embedded beside the interface. The surface is a retained control owned by the same application model as buttons, menus, inspectors, HUDs, dialogs, and ordinary desktop views.

Implemented control

RenderSurface2D

Use one retained tree for game rendering and application UI instead of forcing a realtime loop through a desktop-framework workaround.

  • It derives from ContentControl.
  • It can schedule continuously or only when work is invalidated.
  • Its drawing work participates in retained command and raster reuse.
  • It composes with the rest of Cerneala rather than bypassing it.
Strategic renderer

SDL3 GPU and Cerberus

SDL3 owns the native direction. Cerberus owns SDL3 GPU batching and submission work without becoming a second UI runtime.

  • DrawingContext and DrawCommandList remain the drawing contract.
  • IDrawingBackend remains the backend boundary.
  • Layout, input, state, and invalidation remain root-owned.
  • Visual and performance claims require captured evidence.
CURRENT

Multiple backends still exist

WindowsDX, MonoGame, and SDL3 GPU paths are present. SDL3 GPU has completed its initial end-to-end backend plan, but some samples still default to MonoGame. Documentation must say that until the defaults actually move.

NEXT

MonoGame retires gradually

There is no fake removal date. The adapter stays available during transition. Compatibility expectations and the removal policy must be documented before deletion.

Known incomplete areas

Existing surface area does not mean universal maturity.

Cerneala has a lot of controls and systems. Their maturity is mixed. A familiar type name proves only that the type exists, not that every WPF-shaped scenario or every native platform path is complete.

01 / Native semanticsIncomplete

Accessibility adapters

automationscreen readersnative bridges

Internal semantics and automation exist, but native accessibility adapters are not complete across supported platforms.

02 / Text inputIncomplete

IME, multiline editing, and rich text

IMEselectiondocuments

The full text editing stack still needs platform behavior, shaping, selection, clipboard, accessibility, and lifecycle evidence.

03 / Advanced inputUneven

Touch, stylus, drag and drop

touchstylusmanipulation

Platform-backed advanced input scenarios have uneven maturity and must not be presented as complete from metadata alone.

04 / DistributionPlanned

Packages and project templates

installupgradesamples

The repository is still source-first. Normal onboarding needs justified package boundaries, templates, a minimal sample, and maintained installation instructions.

05 / BackendsUneven

Feature parity and conformance

WindowsDXMonoGameSDL3 GPU

Backend disagreement establishes a mismatch, not truth. The semantic contract, deterministic scenes, and platform-specific evidence decide which implementation is wrong.

06 / CompatibilityRequired

MonoGame transition policy

versioningdeprecationremoval

The direction is clear, but the public transition contract is not versioned yet. It must exist before the adapter is removed.

Definition of progress

Code written is not a completed roadmap item.

01Contract

The intended behavior and architectural owner are explicit. A convenient implementation does not get to invent product semantics.

02Behavior

Focused tests and the original runtime scenario prove the relevant layout, input, lifecycle, rendering, or language path.

03Conformance

Applicable native smokes, visual diffs, performance measurements, resource checks, and backend comparisons pass.

04Repository

Affected and full suites pass, API changes are reviewed, canonical documentation is current, and remaining uncertainty is recorded.