CONCEPT Cited by 1 source

Graphics API abstraction layer¶

A graphics API abstraction layer is the interface a rendering codebase presents to the rest of its application, separate from the underlying graphics API (WebGL, WebGPU, Metal, Vulkan, D3D12, …). The application makes only abstraction-layer calls; the abstraction layer owns all the backend-specific glue.

Why it's load-bearing¶

For a codebase that wants to:

support multiple backends at once — e.g. a web app that wants both WebGL and WebGPU paths live simultaneously;
migrate between backends gradually — rolling out WebGPU over a long tail without breaking WebGL clients;
support dynamic fallback mid-session from one backend to another;
share code across targets — e.g. C++ renderer that runs both in a browser (via Wasm) and as a native binary, where the native binary uses a different lower-level path to the same graphics API;

all of those benefit from a single abstraction surface. Without it, the application's own code is plumbed to one specific backend and multi-backend work means touching every call site.

Design tensions¶

The abstraction layer must navigate a tension:

Too close to one backend → porting to the other backend is painful because the abstraction leaks that backend's semantics. (Figma's pre-migration interface mirrored WebGL's bind-then-draw model; porting to WebGPU required reshaping the interface first.)
Too abstract → performance suffers because the layer can't use backend-specific optimizations.
Too permissive → allows patterns that are cheap on one backend but catastrophic on the other (e.g. per-uniform writes map fine to WebGL but would be disastrous in WebGPU without batching; see concepts/uniform-buffer).

A mature abstraction layer shapes itself around the newer, stricter backend — forcing the application to adopt future-compatible patterns even on the old backend. This is the shape Figma's 2026-04-21 post describes: WebGPU-like explicit state even on WebGL, encode/submit uniform batching even on WebGL. The WebGL implementation happens to handle it trivially, but the application code is already WebGPU-ready.

Canonical shape¶

A draw call in the abstraction layer carries its full state as arguments:

context->draw(pipeline, vertexBuffer, framebuffer, bindGroup, ...);

The WebGL backend lazily reconciles what's already bound vs what the call needs, rebinding only what changed. The WebGPU backend passes directly to WebGPU's explicit state model. Same call site, two implementations, divergent performance shapes — but the application doesn't see the difference.

Sibling examples outside graphics¶

Database drivers — abstract SQL vs NoSQL vs vector store behind a common repository interface.
AI gateways — one request shape, many model providers, with provider-specific translation inside the gateway; see patterns/ai-gateway-provider-abstraction.
Key-value stores — same get/put/delete/scan surface, very different implementations underneath.

The graphics-API case is the most performance-sensitive of these because the abstraction sits on the 60-fps critical path. Even a small per-call overhead multiplies by thousands of draws per frame.

Seen in¶

sources/2026-04-21-figma-rendering-powered-by-webgpu — the post's architecture section centers on redesigning Figma's existing graphics interface (originally WebGL-shaped) to a WebGPU-shaped model that still cleanly backs WebGL. The abstraction was the enabling substrate for (a) the WebGL bug fixes that came "for free" from the redesign, (b) side-by-side multi-backend running during rollout, (c) mid-session dynamic fallback.