The Real Cost of Building a C++ GUI Framework from Scratch: 87,094 Lines, 4 Hard Problems

Wed, 11 Nov 2026 10:54:31 +0000

A month ago I asked how hard it is to build a cross-platform GUI framework without Qt, SDL, or GLFW — hand-written Win32/X11 window layers, and hand-written D3D12 / Vulkan / OpenGL backends.

I finished it. Zekit is now open source.

GitHub: https://github.com/Z-ze489/Zekit
Gitee: https://gitee.com/z-ze489/Zekit

Pure C++20. Windows / Linux / Android. The window layer talks directly to Win32 and X11. The render layer has three backends: D3D12, Vulkan, and OpenGL. No Qt, no SDL, no GLFW.

This post is not “look, it’s easy.” It’s the bill: what was actually hard, what was just learning an API, and what cost real debugging time.

The numbers first

Own code, excluding vendored FreeType and third-party headers:

Win32 window layer (IMM32, DPI, drag-and-drop): 2,146 lines
X11 window layer (EWMH, XIM, cursors, multi-monitor): 3,370 lines
OpenGL renderer (WGL + EGL + GLProgram + renderer): 1,221 lines
Vulkan renderer (context + renderer + runtime loader): 2,113 lines
D3D12 renderer (context + renderer): 1,489 lines
Software rasterizer fallback: 792 lines
Text (FreeType rasterization + text-edit base): 1,582 lines
Everything else (widget tree, layout, theme, events, 80+ widgets): ~74,000 lines
Total: 87,094 lines

88 public headers. One include path.

Line count shows volume, not difficulty. Four things actually hurt.

1. The same concept, three APIs, three lifetime models

Tutorials teach you “how to create a Vulkan swapchain” or “how to create a D3D12 descriptor heap.” They don’t tell you that the same operation is not a renamed function — it’s a different set of invariants.

Real table from my code:

Frame: GL has none; Vulkan is acquire → draw → present; D3D12 is driven by the context’s frame callback.
Projection matrix: GL uses glUniformMatrix4fv; Vulkan uses push constants; D3D12 uses root constants.
Vertex data: GL uses glBufferSubData; Vulkan uses per-frame-slot VBO/IBO; D3D12 uses a per-frame-slot upload-heap ring buffer.
Textures: GL binds textures; Vulkan uses one descriptor set per texture; D3D12 uses one SRV per texture in a shader-visible heap.
Samplers: GL attaches them to texture parameters; Vulkan uses separate VkSampler objects; D3D12 uses separate sampler descriptors.
Destruction: GL allows glDelete at any time; Vulkan cannot destroy resources still in flight; D3D12 is the same as Vulkan.

The last one is the real trap. GL lets you delete a texture at any time and the driver synchronizes for you — it quietly solves a concurrent resource-lifetime problem. Vulkan/D3D12 do not. You must maintain fences, frame slots, and deferred-release queues yourself, or the GPU reads freed memory and crashes somewhere you can’t see.

So “learn three APIs” is misleading. You maintain three non-equivalent resource-lifetime models and make them look like one DrawFrame.

2. Visual consistency is pixel-level, not API-level

This was the most counter-intuitive part. Once all three backends render, you think you’re done. You’re not: the same button has different corner softness on D3D12 and OpenGL.

I use SDF: vertices carry corner parameters, the pixel shader computes a distance field, no geometry tessellation. Sounds clean. Here’s a comment I added back into the code afterward:

“Alpha fades out over exactly 1 pixel at the edge, to match hardware MSAA transition width, so SDF and MSAA are never one sharp and one blurry. Do not widen this band (once written as a 3-pixel smoothstep, every shape went blurry): bandwidth, gradient math, and geometry padding are one set of invariants.”

Translation: the SDF anti-aliasing bandwidth must be exactly 1 pixel, matching hardware MSAA. Once it was 3 pixels, and every shape looked soft. And bandwidth, gradient math, and geometry padding are coupled — change one, the other two must follow.

No spec tells you this. Not Khronos, not MSDN. Only breaking it once, staring at the screen, and fixing it back.

That’s one rounded rectangle. Text anti-aliasing, shadow falloff, stroke pixel alignment, half-pixel offsets at high DPI — all the same pattern.

The first 20% is learning APIs. The last 80% is paying the consistency tax.

3. The platform layer is asymmetric, and the direction is counter-intuitive

Look at the two numbers above: Win32 2,146 lines, X11 3,370 lines. X11 is 55% larger. I did not expect that — the intuition is “Win32 is verbose, X11 is clean.”

Reality:

On Win32, CreateWindowEx + WndProc is a ready-made rule set. IMM32 is one call to ImmSetCompositionWindow to move the composition window to the caret. DPI has SetProcessDpiAwarenessContext.

On X11, you have to wire the window into a modern desktop yourself. _NET_WM_NAME, _NET_WM_ICON, _NET_WM_PID, _NET_WM_WINDOW_TYPE, _NET_WM_STATE (fullscreen/maximized/topmost/hidden), _NET_WM_ALLOWED_ACTIONS, _NET_WM_STATE_SKIP_TASKBAR — miss one of ~20 atoms and the window manager misbehaves, and you won’t see it on your own machine because your WM happens to be forgiving. IME goes through XOpenIM → XCreateIC → Xutf8LookupString; the candidate window position must be computed in screen coordinates and set via XSetICValues with XNSpotLocation, and reset after every ConfigureNotify.

Worse: platform cost is not “number of platforms × constant.” It’s the difference set between platforms. Adding a second platform costs time proportional to how much it differs from the first, not to how complex it is.

And an honest note: I have not done Wayland. Only X11. That is the cost showing.

4. Wrong abstractions compound

The most dangerous part is the only irreversible one.

If the design had been “each backend implements how to draw a rounded rectangle,” then three backends mean three anti-aliasing implementations, never consistent, and every new primitive must be changed in three places. By widget #60, one change opens three files and you die in maintenance.

So the one thing I got right: define the middle layer before writing backends.

Widgets produce one pure-data display list. One vertex format: 13 floats — position, color, UV, plus five rounded-corner SDF parameters. Backends do two things: upload vertices, draw.

Once that layer is correct, the payoff compounds:

Adding a backend is about 800–1,500 lines; the widget layer does not change.
I also wrote window layers for macOS/iOS/Android/HarmonyOS. Source is there, but see the honest ledger below — layering made them cheaper, not finished.
The software rasterizer coexists with GPU backends and verifies geometry, clipping, and text positioning — it removes the GPU driver from the suspect list.

If that display list is wrong, all 80+ widgets get reworked. Wrong abstractions don’t charge you on day one; they charge you in year one.

Difficulty, in units

Taking “first backend puts pixels on screen” as 1 unit:

Open a window + draw a rectangle: 1×. One week, no real difficulty.
One backend with anti-aliased rounded corners + UTF-8 text + emoji: 2–3×. Font rasterization, SDF, MSAA, DPI.
Second backend at pixel-level consistency: 3–5×. Lifetime semantics, precision differences, the invariants above.
Text input (IME/caret/selection/undo/scrolling): 4–6×. Completely unrelated to graphics APIs. Pure time.
Three platforms × three backends fully consistent: 8×+. Platform difference set explodes.
All of the above, plus “user includes one header and it works”: +2×. Vendoring dependencies, runtime loading, build system.

Note the fourth line: what makes people give up is not D3D12. It’s the IME.

Behind ImmSetCompositionWindow / XSetICValues is a state machine: where the composition string is drawn, who the candidate window follows, when it counts as commit, where backspace goes. It has nothing to do with the GPU, and it eats half your debugging time — because the bugs are “sometimes,” “occasionally,” “under this one IME.”

And to be clear: if you only want a button that clicks, this cost is meaningless. Use ImGui or Qt. This breakdown is for people who want to understand how the bottom layers actually turn.

If you actually want to try it, an order that saves detours

Define the display list before writing backends. Reversed order guarantees rework.
Write backend #0 as a software rasterizer. A few hundred lines, no driver dependency, verifies geometry, clipping, text positioning. When the GPU misbehaves, you know whose fault it is.
Do not write D3D12 first. Order: GL (shortest path to pixels) → Vulkan (most verbose but most predictable) → D3D12 (most traps in memory, descriptors, fences).
Each backend implements only four functions: Init / DrawFrame / Resize / Shutdown. Add nothing else.
The text layer must not depend on the graphics API. FreeType produces bitmaps only. Keep this rule and changing backends never touches text.
Get one platform fully working before starting the second. Parallel dual-platform is the most common way to die.

Honest ledger

Current real status:

Windows 10/11 x64: primary. D3D12 / OpenGL 4.6 / Vulkan 1.0+.
Linux x64: supported. EGL OpenGL / Vulkan. X11 only, no Wayland.
macOS / iOS: source present, not compiled on real hardware. Metal backend written but unverified.
Android: source present, emulator only. Mouse input on 2-in-1 devices not solved.
HarmonyOS: source present, emulator only.

Only Windows and Linux are deliverable. The other three are products of “layering made them cheaper,” not “finished.”

And a harder statement: this does not prove that hand-writing a GUI framework is a reasonable choice. It proves that the cost can be quantified — 87,094 lines, four real hard problems, one correctly defined middle layer.

The repository is MIT. Windows builds Zekit.lib, Linux builds libZekit.a. One file. No FreeType install, no Vulkan SDK install.

87,094 lines is a lot of surface area. I can't claim all of it is bug-free — X11 window handling and IME are the parts I'd audit first.

DEV Community: 泽