Chapter 29 Windows 2D: Direct2D and GDI
DIRECT2D and GDI share a platform and a 2D scope, but not a rendering architecture. Direct2D submits retained native drawing commands. GDI presents a CPU-raster bitmap produced by the same software core used by the platform-independent SOFTWARE renderer.
| Identity | Delivery path | 3D result | RT / MRT / query |
|---|---|---|---|
| DIRECT2D | ID2D1 over Windows/Wine D2D, D3D11, and DXGI components | inherited route rejects | yes / no / no |
| GDI | privately composed CPU 2D raster, then Win32 DIB presentation | explicit rejection | yes / no / no |
29.1 DIRECT2D: a different Windows delivery stack
The renderer is not a simplified mode of DIRECTX11. It calls the ID2D1 API and has no shader stage. Under Wine or Proton it relies on those environments’ own built-in D2D, D3D11, and DXGI components; every registered path skips the project’s ordinary DXVK gate. Replacing those built-ins with DXVK changes the delivery stack being tested.
Sprite and shape work is expressed through native 2D resources and commands. The renderer implements RenderTarget2D, but neither MRT nor occlusion queries. Effect-aware 3D methods inherit the common colored route and terminate in the family’s explicit 3D refusal. That is preferable to showing a plausible sprite-colored triangle after discarding a stock effect packet.
29.1.1 Evidence and the release boundary
The repository has a dedicated native-Windows graphics workflow whose matrix includes Direct2D, while local development also uses Wine/Proton. Its Direct2D leg runs the five labelled tests with the D3D11 debug layer, a WARP lifetime pass and a live-object log gate. The renderer’s own release gate remains stricter: it is blocked pending an attributable native adapter/driver run and a physical multi-DPI presentation capture. A workflow definition and even a hosted hidden-window pass do not satisfy those two recorded-evidence criteria.
The practical report for a Direct2D failure must therefore record whether it ran through native Windows or the Wine built-ins, and whether presentation, readback, or only off-screen rendering was observed. A clean device construction proves neither pixel output nor the native release gate.
29.2 GDI: Win32 presentation over the software renderer
The key line in the implementation is now composition, not public inheritance. GdiRenderer derives directly from IGraphicsRenderer and privately owns a GdiSoftware2DCore. The build publishes a reviewed subset of the Software module’s CPU-2D translation units into the GDI archive, and GDI forwards only its intended sprite, texture, target and state operations. No complete Software renderer pointer escapes, so a future Software 3D virtual cannot silently appear in GDI’s public vtable. GDI separately owns the Windows bitmap, damage tracking and DIB presentation edge.
This architecture provides more than a trivial blit. The CPU path has a real standalone 8-bit stencil plane and an opt-in, exact 4x CPU-MSAA backbuffer mode, but no depth buffer. A 2D render target has color, stencil and optional authored mip generation; it deliberately has neither depth nor an MSAA attachment. GDI implements one active 2D target, but not MRT or occlusion queries. Its extended 3D methods reject unsupported input directly rather than relying on the base colored fallback.
29.2.1 Why shared code does not make the identities equivalent
SOFTWARE can run with no native window and returns pixels from its own buffers. GDI must also create, update, and present a Win32 bitmap. A CPU raster test can prove the shared math while missing a stride, channel-order, invalidation, or lifetime defect in the GDI boundary. Conversely, a present smoke test can show a bitmap without distinguishing the depth or stencil semantics beneath it.
The renderer-specific CTests are excluded while cross-compiling, so a Linux-host build cannot execute them merely because it produced a Windows binary. A separate native MSVC workflow is the meaningful automated platform tier.
29.3 Choosing and testing the Windows 2D paths
Choose Direct2D when native ID2D1 resource and composition behavior is the product goal. Choose GDI when a deterministic CPU-rendered image delivered through the classic Win32 surface is valuable. Neither identity is a route to programmable 3D.
A useful comparison scene should include alpha and additive sprites, a clipped draw, a target round trip, and a format-sensitive readback. Add depth, stencil, and MSAA probes for GDI’s shared software core. Run the same scene off-screen and through real presentation so the raster and delivery boundaries are tested separately.