upp_render

upp_render is a backend-neutral GPU rendering layer for Ultimate++.

The ordinary application entry point is GpuRender. Add that package and include:

#include <GpuRender/GpuRender.h>

Application code does not need HWNDs, Vulkan handles, queue families, swapchains or command buffers.

Three ways to use it

1. Embedded GPU surface

Use GpuCtrl inside an ordinary U++ window:

GpuCtrl view;
view.SetGpuPaint([](GpuPainter& w) {
    Size sz = w.GetSize();
    w.Clear(Color(24, 31, 45));
    w.FillRect(Rectf(20, 20, sz.cx - 20, sz.cy - 20), Color(62, 112, 214));
    w.DrawText(Pointf(40, 42), "GPU content", SansSerif(24).Bold(), White());
});

TopWindow win;
win.Add(view.SizePos());
win.Run();

GpuCtrl owns the native embedded presentation surface. The rest of the window can remain ordinary U++/GDI controls.

2. Whole custom GPU window

Subclass GpuWindow when the full client area is application-owned GPU content:

class View : public GpuWindow {
    void GpuPaint(GpuPainter& w) override {
        w.Clear(Black());
        w.DrawText(Pointf(30, 30), "Whole GPU window", SansSerif(28), White());
    }
};

3. GPU-composited U++ interface

Use GpuTopWindow when U++ should keep control/layout/input/theme authority while the resolved control tree is recorded and replayed through one root GPU surface:

class MainWindow : public GpuTopWindow {
public:
    MainWindow() {
        SetAsyncPresentation();
        Add(button.LeftPos(20, 120).TopPos(20, 32));
        button.SetLabel("Ordinary U++ button");
    }
private:
    Button button;
};

Current rendering capability

The accepted/implemented stack includes:

• immutable backend-neutral display lists;
• software reference replay;
• Vulkan 1.3 bootstrap, surfaces, swapchains and frame presentation;
• filled/stroked/rounded geometry;
• clipping, affine transforms, alpha/source-over and batching;
• sampled images, including caller-owned GPU textures without CPU image copies;
• optional bounded storage-buffer compute, device-local output and GPU buffer-to-image transfer;
• shared native Ui text shaping/editing, glyph-ID snapshots and persistent GPU glyph atlases;
• direct GPU convex fills/closed miter and straight strokes with antialiased coverage;
• general paths, gradients, other strokes and SVG through the bounded U++ Painter reference path;
• embedded GpuCtrl presentation;
• full-window custom GpuWindow presentation;
• U++ control-tree recording and GpuTopWindow root composition.

Historical Stage-5/H1/UI1-C acceptance is retained. Current whole-UI completion is 5/10 gates (50%), with general vectors, glyph preparation and shared Ui raster helpers still open. Direct geometry uses single-sample antialiased coverage; complex vectors/SVG retain cached CPU coverage. See current scope.

Shared application GPU context

Ordinary presenters use GpuContext::Default(). Compatible Vulkan presenters now share the expensive application/device domain: runtime, instance, physical/logical-device ownership, selected queue handles, and one device-level pipeline cache. Each presenter still owns its own native surface, swapchain and frame lifecycle.

Logical image/glyph handles and presentation state remain independent. Immutable images now share native allocations under stable identity and reference lifetimes. Image/vector/glyph retention has configured bounds; integer-moving vectors reuse their shape content. Mutable glyph atlases remain renderer-owned.

The generic provider registry lives below the public façade in RenderRhi; the Vulkan provider registers itself from RenderVulkan. GpuRender.upp currently depends on RenderVulkan so a normal Windows/Vulkan application still gets the default provider simply by adding the one public package. That is build composition, not a Vulkan dependency in the public drawing or presentation API.

Packages

Ordinary application developers should normally care about only:

• GpuRender — public U++ integration façade.

The remaining packages are deliberate renderer/backend layers:

• RenderCanvas — neutral display list and GpuPainter recording;
• RenderCore — backend-neutral value types;
• RenderGpu2D — GPU 2D replay engine;
• RenderRhi — backend contract and internal provider registry;
• RenderVulkan — current Vulkan implementation/provider;
• RenderSoftware — correctness/reference renderer;
• RenderVector — vector/Painter authority;
• RenderNull — headless validation backend;
• RenderPlatformWin32 — current native-window adapter.

See render/README.md for the dependency map.

Examples

The three product demonstrations are:

• GpuSurfaceDemo — adjustable embedded Vulkan surfaces in the Ui shell;
• examples/GpuUiGallery — ordinary Ui controls in Vulkan root/dialog windows, including an embedded animated compute image, exposure, optional final quantization dithering and live FPS;
• examples/RendererShowcase — rendering capabilities and software/GPU comparison.

Three small source tutorials cover GpuCtrl, GpuWindow and GpuTopWindow; see examples. Historical bring-up and stock-control compatibility probes are indexed under diagnostics.

Version 1 preparation

Windows/Vulkan finishing work now includes immutable image sharing, bounded content caches and an optional GpuTopWindow presentation worker. The whole-Ui gallery passes measured UI-delay targets under a 512-particle validation-enabled workload on the declared reference GPU. Shared Windows text layout now covers complex scripts, rich text, native IME composition and supported colour/bitmap fonts; text contracts and limits and current candidate qualification record the exact scope. The Windows frame clock now avoids a reproduced old-input lost wake; current Release/Debug and two five-minute load tests pass. Wakeup diagnosis and exact measurements retain before/after evidence. Strict Windows acceptance is 8/10 (80%); physical input/DPI/IME and current clean-machine release review are recorded separately. GpuCtrl::SetGpuContent now supplies an owned custom-content hook for precompiled shaders/compute through the device API. Shipped apps do not need the Vulkan SDK. See compute contract and measured results; this does not establish async video streaming or an OCIO pipeline.

See release scope and gates, sustained RC1 qualification, BGFX design review and current evidence.

Backend roadmap

Vulkan is the currently validated backend. Metal and WebGPU are first-class planned backends and the public API is intentionally kept free of Vulkan types.

• Metal: macOS first, while keeping the design viable for iOS/iPadOS presentation models.
• WebGPU: native/browser backend, with a longer-term goal of allowing U++ rendering/control intent to run in a WebAssembly/browser host. This requires browser platform/event/input work in addition to the renderer backend itself.

See docs/BACKEND_ROADMAP.md.

Build status

Windows/Vulkan is the currently validated platform. Use the repository CLANGx64_Vulkan.bm environment/build method and a Vulkan SDK available to the local U++ toolchain. Platform-specific paths belong in local configuration, not application code.

Productization/H1 and UI1-C have recorded Windows/Vulkan acceptance. Current Windows/Vulkan finishing evidence is in WINDOWS_VULKAN_V1. Broader resource convergence and future backends remain separate work. GpuSurfaceDemo demonstrates the embedded-control product goal with two adjustable surfaces; its focused checks do not replace the full historical regression matrix. For current validation boundaries, see docs/ACTIVE_WORK.md.