Skip to main content

Backend Architecture

Kanvas exposes one renderer-facing contract and keeps platform graphics APIs behind native backend implementations.

Backend existence is not certification

A backend being present in the source tree means there is an implementation path. It does not imply broad validation across GPU vendors, drivers, resize/device-loss cases, or every Compose operation.

Current backend source:

The native build graph is defined in native/CMakeLists.txt.

Why the backend boundary is below JNI​

The renderer should not need one Kotlin implementation for Metal, another for Vulkan, and another for Direct3D.

Instead:

same frame command model
        │
        ▼
native backend dispatch
   ┌────┼─────┬─────┐
 Metal Vulkan GL   D3D9

That keeps platform-specific swapchain/device/window code in the language and build environment where those APIs are naturally available.

Why keep GDI?​

GDI is not marketed as GPU acceleration. It remains useful as a Windows reference/software path.

A reference path helps separate:

  • "our command lowering is wrong"
  • from "this GPU backend is wrong"

That distinction is valuable during backend development.

Why Vulkan can build with stubs​

The CMake build can produce ABI-compatible Vulkan stubs when a real Vulkan loader is unavailable, unless Vulkan is explicitly required.

This allows the broader library and non-Vulkan tests to compile on hosts where Vulkan is not usable.

A stub is not Vulkan support

Successful compilation with a Vulkan stub does not mean the machine can render through Vulkan. Runtime/backend verification remains separate.

Source: native/CMakeLists.txt