DEV Community: Andrey Kolkov

gogpu/ui v0.1.21: Enterprise Render Pipeline — Layer Tree, Damage Tracking, 0% GPU Idle

Andrey Kolkov — Tue, 12 May 2026 10:23:08 +0000

Two months ago we released gogpu/ui v0.1.0 — 22 widgets, 3 design systems, ~150K lines of pure Go. Since then we shipped 21 patch releases, and the rendering pipeline is unrecognizable.

This post covers what changed and why it matters.

The Problem

v0.1.0 re-rendered the entire widget tree every frame. A 48×48 spinner in one corner caused the GPU to redraw 800×600 of static content. Hover over a button? Full tree walk. Open a dropdown? Full tree walk. This was fine for demos, not for production.

We studied how five frameworks solve this — Flutter, Chrome, Qt6, Android HWUI, Skia — and found the same architecture everywhere: Layer Tree + boundary isolation + damage tracking.

What We Built (v0.1.14 → v0.1.21)

Layer Tree Compositor

Every RepaintBoundary widget now owns a node in a persistent Layer Tree:

OffsetLayer (root)
├── PictureLayer (toolbar — clean, reuse texture)
├── PictureLayer (sidebar — clean, reuse texture)
├── ClipRectLayer (scrollview viewport)
│   └── PictureLayer (content — dirty, re-record)
└── PictureLayer (spinner — dirty, re-record 48×48)

Four layer types — OffsetLayer, PictureLayer, ClipRectLayer, OpacityLayer — compose the frame. Clean layers reuse their GPU texture from the previous frame. Only dirty layers re-render.

This is the same pattern Flutter calls flushPaint + compositeFrame. We validated it against all five reference frameworks before writing a line of code.

0% GPU When Idle

The frame loop checks a flat dirty set — O(1), not O(n) tree walk:

if !w.HasDirtyBoundaries() && !w.NeedsRedraw() && !w.NeedsAnimationFrame() {
    return // nothing changed, skip frame entirely
}

When the UI is idle, the GPU does zero work. Measured: 0% GPU across all six examples (hello, signals, taskmanager, gallery, ide, modular-compositor).

Previous approach walked the entire widget tree every frame to check if anything needed redraw. For 200 boundaries, the new approach is 45× faster.

Per-Boundary GPU Textures

Each RepaintBoundary renders into its own offscreen MSAA texture. When a child boundary becomes dirty, only that boundary's texture is re-rendered. The compositor blits all textures in a single non-MSAA pass.

A 48×48 spinner touching 2,304 pixels no longer forces the GPU to process 480,000 pixels of unchanged content.

Multi-Rect Damage

When multiple widgets are dirty in different screen regions, we don't union them into one giant rect. Each dirty rect gets its own GPU scissor:

Frame N: spinner (48×48) + status bar (800×24)
→ Two scissor rects, not one 800×600 rect
→ Zero pixel waste

The damage pipeline flows through the full stack: ui → gg RenderDirectWithDamageRects → wgpu PresentWithDamage. Ring buffer stores rect lists for N-buffer swapchains. Threshold at 16 rects merges to union (GDK/Sway pattern).

Persistent Layer Tree

UpdateLayerTree() reuses layer objects across frames instead of rebuilding the tree:

Metric	Before	After
Allocs per frame (200 boundaries)	613	13
Reduction	—	97.9%

Flutter calls this addRetained. Android calls it RenderNode reuse. We measured allocation profiles against both and matched their patterns.

The Numbers

Metric	v0.1.0	v0.1.21
Lines (total / code)	150K / 105K	195K / 141K
Tests	6,000	7,200+
Coverage	97%	97%+
Packages	56	56
GPU idle (static UI)	5-18%	0%
Frame skip check	O(n) tree walk	O(1) flat set
Allocs/frame (200 boundaries)	613	13
Spinner GPU work	full window	48×48 scissor

Ecosystem Update

The rendering pipeline required changes across four repositories. Here's where the ecosystem stands:

Repository	Version	Lines	Code	What It Does
naga	v0.17.13	323K	240K	Shader compiler: WGSL → SPIR-V, MSL, GLSL, HLSL, DXIL
gg	v0.46.8	240K	171K	2D graphics: Skia-class rasterizer, GPU SDF, scene compositor
wgpu	v0.27.3	211K	164K	Pure Go WebGPU: Vulkan, DX12, Metal, GLES, Software
ui	v0.1.21	195K	141K	GUI toolkit: 22 widgets, 4 themes, Layer Tree pipeline
gogpu	v0.34.3	61K	45K	App framework: windowing, input, three-mode render loop
+ gpucontext, gputypes, systray, audio	—	19K	13K	Shared interfaces, system tray, audio engine
Total		1,049K	774K	3,140 files across 9 repositories

1M+ total lines. 774K lines of code. Zero CGO. Zero Rust. Zero C.

Recent ecosystem highlights since the v0.1.0 article:

First Pure Go DXIL generator — naga compiles WGSL shaders directly to DXIL bytecode, eliminating the HLSL→FXC/DXC dependency. 161/170 IDxcValidator pass rate. Article.
Born ML v0.8.0 migrated to gogpu/wgpu — production ML framework running on our GPU stack. 105 GPU tests pass, HRM model trained 20 epochs. Article.
CJK text rendering — script-aware hinting, exact-size rasterization, Tier 6 routing for Chinese/Japanese/Korean glyphs.
LCD ClearType auto-detection — Windows SPI + registry, macOS None, Linux Xft/Wayland. Per-platform subpixel layout.
Software backend for CI — deterministic GPU without GPU hardware. Pixel-exact e2e tests prove scissor rects at HAL level.
Community deep-dive — independent technical analysis of gogpu/wgpu (Chinese) covering the zero-CGO syscall architecture, Snatchable resource lifecycle, and buffer state tracking internals. Always good to see the community dig into the implementation.

The Foundation Is Ready

This is the release where we stopped rebuilding and started building on top.

For the past two months every release was infrastructure: retained-mode rendering, scene composition, Layer Tree, damage tracking, boundary isolation. The kind of plumbing that's invisible to users but determines whether a framework can scale to real applications.

That plumbing is now in place. The render pipeline follows the same architectural patterns as Flutter, Chrome, and Qt6 — not because we copied them, but because we studied all five independently and arrived at the same conclusions. Layer Tree composition, per-boundary GPU textures, multi-rect damage, persistent allocation — these are industry-proven patterns, and they're production-ready in gogpu/ui.

The ecosystem has stabilized around this architecture. naga (shader compiler), wgpu (WebGPU HAL), gg (2D graphics), and gogpu (windowing) all reached the point where API churn is minimal and releases are incremental improvements, not rewrites. Nine repositories, 1M+ lines, and the dependency chain holds.

What this means going forward: the pipeline will be optimized, not rebuilt. Future releases will focus on:

New widgets — the 22 we ship today cover most use cases, but enterprise apps need more (color picker, date picker, rich text editor, tree grid)
Performance polish — reducing GPU usage for animated widgets from 10% to <3%, ListView recycling, texture GC
Platform accessibility — UIA on Windows, AT-SPI2 on Linux, NSAccessibility on macOS
Developer experience — better docs, more examples, smoother onboarding

The hard part is behind us. The interesting part is ahead.

Try It

git clone https://github.com/gogpu/ui.git
cd ui/examples/gallery
go run .

Four design systems ship out of the box: Material Design 3, JetBrains DevTools, Microsoft Fluent, Apple Cupertino. Switch between them at runtime in the gallery example.

Backend selection via environment variable:

GOGPU_GRAPHICS_API=vulkan   go run ./examples/ide/
GOGPU_GRAPHICS_API=dx12     go run ./examples/ide/
GOGPU_GRAPHICS_API=gles     go run ./examples/ide/
GOGPU_GRAPHICS_API=software go run ./examples/ide/

No code changes needed.

Help Us Get There

gogpu/ui is at the stage where the architecture is proven but the user base is small. We need real-world testing to catch edge cases that no amount of 97% coverage will find.

Test it. Clone a repo, run an example, try building something with it. If it breaks — that's valuable. File an issue, and we'll fix it. If it works — that's valuable too. Tell us what you built.

Spread the word. Most Go developers don't know this exists yet. A post on Reddit, a tweet, a mention in your team's Slack — it all helps. The project grows through people who try it and talk about it, not through marketing.

Write about it. Tutorials, experience reports, comparisons, critiques — all welcome. If you build something interesting with gogpu/ui, write about the process. The ecosystem needs content from people other than us.

Contribute. You don't need to touch the render pipeline. Documentation improvements, new examples, widget ideas, accessibility testing, CI on different hardware — there's work at every level. Check CONTRIBUTING.md or just open a discussion.

The codebase is 1M+ lines of pure Go with zero CGO. The foundation is solid. What it needs now is people building on it.

GitHub · Discussions · CHANGELOG · Reddit r/golang · X/Twitter

Born ML v0.8.0: We Killed Our Last .dll — Pure Go GPU Is Here

Andrey Kolkov — Sun, 03 May 2026 12:41:30 +0000

TL;DR: Born v0.8.0 replaces go-webgpu (Rust FFI + shared libraries) with gogpu/wgpu — pure Go WebGPU. No .dll. No .so. No runtime downloads. go build now gives you a GPU-accelerated ML binary. We also fixed 5 critical GPU bugs and validated on real model training. Next up: DeepSeek V4 inference support.

The Last Dependency

Five months ago I skipped my birthday to release Born. A few weeks later we made training 18x faster with lazy GPU evaluation. The framework was growing. Contributors were showing up. Real people were using it.

But there was a problem I couldn't ignore anymore.

Every time someone wanted to use GPU acceleration, the conversation went like this:

"How do I run the GPU examples?"

"Download wgpu-native .dll for your platform, put it in your PATH..."

"...I thought you said pure Go?"

They were right. Born's CPU path was pure Go. But the GPU backend used go-webgpu — Go bindings to Rust's wgpu-native via FFI. You needed a platform-specific shared library at runtime. On Windows, a .dll. On Linux, a .so. On macOS, a .dylib.

For a framework whose tagline is "single binary deployment", that was embarrassing.

So we fixed it.

Why Not Earlier?

Fair question. gogpu/wgpu existed for months before v0.8.0. Why did we ship 29 releases on go-webgpu first?

Because that was the plan.

go-webgpu wraps Rust's wgpu-native — a battle-tested GPU abstraction used by Firefox and dozens of production projects. When you're building a new ML framework from scratch, you don't want to debug your GPU backend and your tensor math at the same time. If training produces wrong gradients, is the bug in your autodiff engine or in your WebGPU implementation? With Rust wgpu-native underneath, we knew: the GPU layer works. Any bug is ours.

So we built Born v0.1 through v0.7 on a proven foundation. Tensor ops, autodiff, attention, Flash Attention, speculative decoding, ONNX import, GGUF loading — all validated against a GPU backend we could trust. By v0.7.16, Born had 1,394 tests, 3 external contributors, and real model training working.

Meanwhile, gogpu/wgpu was maturing through its own path — powering gogpu/gg (2D graphics library with GPU compute shaders), running real rendering workloads, stabilizing the Core API across Vulkan, Metal, DX12, and GLES.

When both sides were proven, the migration became simple: we knew Born's code was correct, and we knew gogpu/wgpu's Core API was stable. Any bug found during migration was specifically a wgpu Go integration issue — easy to isolate, easy to fix.

That's exactly what happened. Five bugs, all in resource lifecycle. All fixed in days, not weeks.

Validate on proven foundation first. Swap the foundation second. This is not how you move fast. This is how you move right.

The Migration

Born v0.8.0 replaces go-webgpu with gogpu/wgpu — a pure Go WebGPU implementation from our own GoGPU ecosystem.

- github.com/go-webgpu/webgpu v0.4.1
+ github.com/gogpu/wgpu v0.26.8

One line in go.mod. 27 files changed. 1,830 additions, 1,518 deletions.

What changed:

	go-webgpu (before)	gogpu/wgpu (after)
Implementation	Rust wgpu-native via FFI	Pure Go
CGO	None (goffi)	None
Runtime .dll/.so	Required	None
Build	`go build` + download .dll	`go build`. Period.
Vulkan/Metal/DX12	Via Rust	Via Go
WGSL shaders	Unchanged	Unchanged
Control	External project	Our project

That last row matters. gogpu/wgpu isn't some random dependency — it's our project. When Born needs a WebGPU API change, we change it upstream. Both sides of the interface are under our control.

Five Bugs Nobody Told Us About

Swapping the GPU backend is like replacing a car engine while driving. Everything looks the same from the outside, but internally the timing, resource lifecycle, and synchronization are completely different.

We found five critical bugs during migration:

1. PipelineLayout Freed Too Early

Vulkan requires compute pipeline layouts to stay alive during SetBindGroup(). go-webgpu's internal reference counting kept them alive. gogpu/wgpu doesn't — you own your resources.

We fixed this by storing PipelineLayout alongside the pipeline in our cache.

2. Lazy Ops and the Destroy Queue

Born uses lazy evaluation — GPU ops chain without CPU sync. But when a tensor gets garbage-collected mid-chain, its buffer goes to the destroy queue. If the pending operations haven't submitted yet, the buffer is destroyed before the GPU reads it.

Fix: immediate submit for lazy ops. Every operation submits its command encoder before returning.

3. Buffer Copy Race

copyGPUBuffer (used by Data() to read results back to CPU) was queuing the copy but not submitting. The next operation might overwrite the source buffer before the copy executed.

Fix: immediate submit after copy.

4. GC vs GPU

Go's garbage collector doesn't know about GPU resources. A runtime.SetFinalizer on a tensor could fire while the GPU was still computing with that tensor's buffer.

Fix: runtime.KeepAlive() guards around every GPU operation that uses the tensor.

5. Device Cleanup Order

When destroying the GPU device, all pending work must complete first. Without Poll(PollWait) before resource destruction, Vulkan validation layers scream.

Fix: explicit Poll(PollWait) in Release() to ensure GPU idle.

None of these bugs existed with go-webgpu. They're all about resource lifecycle differences between Rust's ownership model (where wgpu-native tracks everything for you) and Go's GC-based model (where you track it yourself).

After fixing all five, we ran all GPU tests and a 20-epoch model training with zero crashes.

What You Get

True Single Binary

go build -o myapp ./cmd/myapp
# That's it. Ship the binary. GPU works.

No .dll downloads. No LD_LIBRARY_PATH. No platform-specific install steps. The binary works on any machine with a Vulkan-capable GPU.

Same API, Same Shaders

If you have existing Born code with GPU, nothing changes:

import (
    "github.com/born-ml/born/backend/cpu"
    "github.com/born-ml/born/autodiff"
)

// CPU-only (always worked)
backend := autodiff.New(cpu.New())

import "github.com/born-ml/born/backend/webgpu"

// GPU-accelerated (now pure Go!)
if webgpu.IsAvailable() {
    gpu, _ := webgpu.New()
    backend := autodiff.New(gpu)
    defer gpu.Release()
}

WGSL shaders are unchanged. The Backend interface (52 methods) is unchanged. Your code just works — minus the .dll.

Validated on Real Training

We didn't just run unit tests. We trained a real Hierarchical Reasoning Model (HRM) for 20 epochs on GPU. Zero crashes. Correct gradients. Same accuracy as go-webgpu.

The Numbers

Metric	Value
Go source	~47K LOC
Tests	~34K LOC, 1,394 test functions
ONNX operators	49
Backend methods	52
GPU tests	105
Contributors	4 (@kolkov, @gmohmad, @bennibbelink, @jsully1720)
Releases	30
Stars	80 (organic, no marketing)

Community

v0.8.0 isn't just about the migration. Since v0.7.0, three external contributors have landed real code:

@jsully1720 — ONNX Equal operator
@bennibbelink — Erf, Sign/Abs, Clamp ops (3 PRs, all full vertical slices: backend → CPU → GPU → autodiff → tests)
@gmohmad — LayerNorm, BatchMatMul broadcasting, Squeeze fix, 9 new ONNX ops, inplace mutation bug fix (5 PRs)

These aren't drive-by typo fixes. These are production-quality contributions from people who studied the codebase and followed the patterns. If you're considering contributing, look at what they did — that's the bar.

What's Next: DeepSeek V4 Inference

With the GPU backend stable and pure Go, we can focus on what matters: running real models.

DeepSeek released V4 on April 24, 2026 — two models:

V4-Pro: 1.6 trillion params, 49B active
V4-Flash: 284B total, 13B active — fits on a consumer GPU

V4-Flash with 13B active parameters is Born's sweet spot. It's the most capable open model that fits on a single 24GB GPU. API pricing is tied to chip availability ($1.74/M tokens, bottleneck pricing) — users want local inference alternatives.

We started researching V4 architecture before it launched — back in early April, when only the Engram paper and V3.2 sparse attention existed. We predicted V4 would combine MoE + Engram + manifold-constrained residuals + compressed sparse attention. On April 24th, the tech report confirmed all four. Two weeks head start on architecture analysis. (We do this kind of research openly — see Discussion #60 for our Recurrent-Depth Transformer analysis.)

Here's the full component breakdown:

Component	What	Why It Matters
MoE Routing	Top-16 sparse expert selection	Also unlocks Mixtral, DBRX
MXFP4 Dequantization	FP4 expert weights with block scaling	V4's native format — not INT4 GPTQ
Engram	O(1) hash-lookup factual memory	Unique to DeepSeek, DRAM-resident
Three-Pool Attention	SWA + C4 + C128 compression	1M context with <10% throughput drop
Hyper-Connections (mHC)	4D manifold-constrained residual	Every transformer layer uses this
MTP Drafting	Integrated speculative decoding	~2.5 tokens accepted per step
KV Cache Tiering	CPU-GPU cache with LRU eviction	128K+ context on 24GB consumer GPU
PD-Disaggregation	Prefill/Decode split serving	Production throughput scaling

Total estimate: 22-30 weeks. It's a lot. But MoE routing alone unlocks V4, Mixtral, and BAR (Allen AI's modular post-training). Each component is independently valuable.

The GoGPU Ecosystem

Born's GPU backend is powered by the GoGPU ecosystem — pure Go GPU infrastructure:

Project	What	LOC
gogpu/gg	2D graphics with GPU compute shaders	~222K
gogpu/naga	Shader compiler (WGSL → SPIR-V, MSL, HLSL, GLSL, DXIL)	~199K
gogpu/wgpu	Pure Go WebGPU (Vulkan, Metal, DX12, GLES, Software)	~156K
gogpu/gogpu	Graphics framework + windowing	~52K

Combined with Born's ~81K LOC, that's 710K+ lines of pure Go GPU code. No CGO. No Rust. Just go build.

Try It

git clone https://github.com/born-ml/born
cd born
go build ./...
go test ./... -short

Run the examples:

cd examples/mnist && go run .       # MLP: 97.44% accuracy
cd examples/mnist-cnn && go run .   # CNN: 98.18% accuracy
cd examples/mnist-gpu && go run .   # GPU-accelerated inference

GPU examples now work with go run — no .dll download step.

Build This With Us

Born is at an inflection point. GPU is stable. The architecture is proven. The roadmap to DeepSeek V4 is clear.

We're not looking for passive users. We're looking for people who want to help build one of the best ML frameworks in the world. In Go.

How you can make a difference:

File issues. Found a bug? A missing operator? An edge case that breaks your model? Every issue makes Born more production-ready. Our three external contributors started exactly this way.
Send PRs. Missing tensor ops (TopK, Scatter — needed for MoE), CPU optimizations (the inner loops are naive — lots of low-hanging fruit), new ONNX operators, quantization infrastructure. Look at what @bennibbelink and @gmohmad have done — full vertical slices, production quality. That's the standard.
Bring breakthrough ideas. The hardest problems ahead — MoE routing, FP4 dequantization, compressed sparse attention, CPU-GPU cache tiering — are open research questions in Go. If you have insights on how to make these work efficiently in pure Go, we want to hear them.
Challenge our assumptions. Tell us what we're doing wrong. Tell us what's missing. The best frameworks are shaped by people who care enough to argue.

Found a bug? Open an issue
Have a big idea? Feature Requests & Roadmap Discussion
Questions? Getting Started & FAQ
Ready to code? Contributing Guide

Links

Resource	Link
GitHub	github.com/born-ml/born
v0.8.0 Release	Release Notes
Documentation	pkg.go.dev/github.com/born-ml/born
Roadmap	ROADMAP.md
Changelog	CHANGELOG.md
GoGPU	github.com/gogpu

Five months ago, Born was a birthday project with zero stars. Today it's a pure Go ML framework with GPU acceleration, 4 contributors, 49 ONNX operators, and a roadmap to run DeepSeek V4.

No .dll. No .so. No excuses. Models are born production-ready.

go build. Ship. Done.

Star us on GitHub: github.com/born-ml/born

We Built a Pure Go System Tray Library Because Every Alternative Requires CGO, GoGPU May 2026

Andrey Kolkov — Thu, 30 Apr 2026 21:10:33 +0000

"Love the no CGO — but quickly realized there's no code?"
— @cmilesio, gogpu/systray#1

Fair point. We published the repo with just a README and a dream. Three days later: 5,800+ lines of Pure Go, three platforms, 74 tests, 84% coverage, and a working system tray icon on Windows.

Today we're releasing gogpu/systray v0.1.0 — the first Pure Go system tray library that works on Windows, macOS, and Linux without a C compiler.

The Problem

Every Go system tray library requires CGO:

Library	Stars	CGO?	The Catch
getlantern/systray	3.3K	Yes (macOS, Linux)	AppIndicator + GTK3 on Linux, Cocoa via CGO on macOS
fyne-io/systray	fork	Yes (macOS, Linux)	Same CGO deps, fork of getlantern
energye/systray	—	Yes	Walk/LCL dependency

CGO means:

Need a C compiler installed (apt install gcc, Xcode, MinGW)
Cross-compilation breaks (GOOS=linux from macOS? Good luck with CGO)
Larger binaries, slower builds
CGO_ENABLED=0 doesn't work

Go is famous for "single binary, cross-compile anywhere." CGO breaks that promise.

The Solution: Native APIs via Pure Go FFI

We went platform-native without CGO:

Platform	Native API	Go FFI	LOC
Windows	`Shell_NotifyIconW` (shell32.dll)	`golang.org/x/sys/windows`	1,027
macOS	`NSStatusBar` / `NSStatusItem` (AppKit)	`go-webgpu/goffi` (ObjC runtime)	1,385
Linux	StatusNotifierItem (D-Bus SNI)	`godbus/dbus/v5`	810

No C compiler. No shared libraries. No dlopen of GTK. Just Go talking directly to the OS.

Windows: Shell_NotifyIconW

The Win32 approach is straightforward — Shell_NotifyIconW has been the tray API since Windows 95. We call it via golang.org/x/sys/windows, the same way the Go standard library talks to Windows.

Key details:

Message-only HWND for callbacks (invisible, no taskbar entry)
NOTIFYICON_VERSION_4 for modern event dispatch
Explorer crash recovery — when explorer.exe restarts, tray icons disappear. We listen for the TaskbarCreated registered message and re-add the icon automatically.
Dark mode auto-switching — detect WM_SETTINGCHANGE + ImmersiveColorSet, read SystemUsesLightTheme registry key, swap HICON. Your tray icon adapts when the user toggles Windows dark mode.

macOS: NSStatusBar via ObjC Runtime

This is where it gets interesting. Calling AppKit without CGO requires speaking the Objective-C runtime protocol:

objc_getClass("NSStatusBar") — get the class
objc_msgSend(class, sel("systemStatusBar")) — get the shared status bar
objc_msgSend(statusBar, sel("statusItemWithLength:"), -1.0) — create a status item

We built a minimal ObjC runtime wrapper (~490 LOC) using goffi — our Pure Go FFI library. Same approach we use for the Metal GPU backend in gogpu/wgpu.

The killer feature on macOS: template icons.

tray.SetTemplateIcon(monochromePNG)

This calls [NSImage setTemplate:YES], telling macOS the icon is a monochrome mask. The OS automatically renders it white on dark menu bars, black on light ones. No dark mode handling needed — Apple does it for you.

Linux: D-Bus StatusNotifierItem

Linux is the most complex platform. The "system tray" isn't a single API — it's a D-Bus protocol called StatusNotifierItem (SNI).

We implement two D-Bus interfaces:

org.kde.StatusNotifierItem — the tray icon itself:

Properties: Category, Id, Title, Status, IconPixmap, ToolTip, Menu
Methods: Activate (click), SecondaryActivate (middle-click), ContextMenu (right-click)
Signals: NewIcon, NewTitle, NewStatus

com.canonical.dbusmenu — the context menu:

A recursive tree of menu items with labels, types, toggle states
GetLayout returns the full tree, Event dispatches clicks

And a registration dance with org.kde.StatusNotifierWatcher — plus automatic re-registration when the desktop panel restarts.

The PNG→ARGB conversion is a fun detail: SNI wants ARGB32 in network byte order (big-endian), so we decode the PNG with image/png and manually pack [A, R, G, B] bytes.

All of this via godbus/dbus/v5 — the canonical Pure Go D-Bus library. Zero CGO.

The API

We went with a builder pattern inspired by Wails 3:

package main

import (
    "fmt"
    "os"
    "github.com/gogpu/systray"
)

func main() {
    tray := systray.New()

    menu := systray.NewMenu()
    menu.Add("Open", func() { fmt.Println("Opening...") })
    menu.AddSeparator()
    menu.AddCheckbox("Dark Mode", false, func() { fmt.Println("Toggled!") })
    menu.AddSubmenu("More...", systray.NewMenu().
        Add("About", func() { fmt.Println("v1.0") }).
        Add("Help", func() { fmt.Println("Help!") }))
    menu.AddSeparator()
    menu.Add("Quit", func() { tray.Remove(); os.Exit(0) })

    tray.SetIcon(iconPNG).
        SetDarkModeIcon(darkIconPNG).
        SetTooltip("My App").
        SetMenu(menu).
        Show()

    tray.OnClick(func() { fmt.Println("Clicked!") })
    tray.Run() // blocks, pumps platform messages
}

Multiple trays are supported — each call to systray.New() creates an independent icon:

mainTray := systray.New().SetIcon(appIcon).SetMenu(mainMenu).Show()
statusTray := systray.New().SetIcon(statusIcon).SetTooltip("Status: OK").Show()

Enterprise Research

We didn't guess at the architecture. Before writing code, we studied how the big frameworks do it:

Framework	Tray Architecture	Our Takeaway
Qt6	`QPlatformSystemTrayIcon` → 3 platform implementations	Three-layer pattern (public API → interface → platform impl)
Wails 3	`systemTrayImpl` interface, native per-platform	Builder API pattern, multiple tray support
SDL3	4 backends (AppIndicator, D-Bus, Win32, Cocoa)	We chose D-Bus SNI directly, skipping AppIndicator
Electron	`nativeTheme.shouldUseDarkColors`	Dark mode detection via `WM_SETTINGCHANGE`
GLFW	`RemovePropW` before `DestroyWindow`	Destroy pattern (avoid deadlocks)
getlantern/systray	`GetMessage` loop, hidden WS_OVERLAPPEDWINDOW	Message pump pattern (we use `HWND_MESSAGE` instead)

The architecture follows Qt6's QPlatformSystemTrayIcon pattern:

systray.New()  →  SystemTray (public API, delegation)
                       │
                  PlatformTray (internal interface)
                       │
          ┌────────────┼────────────┐
     Win32 impl   macOS impl   Linux impl
     Shell_Notify  NSStatusBar   D-Bus SNI

Why Not AppIndicator on Linux?

The tempting path: dlopen("libayatana-appindicator3.so.1") and let GTK3 handle everything. That's what getlantern/systray does (via CGO).

Problems:

Pulls in GTK3 runtime — gigantic dependency for a tray icon
It's just a wrapper around SNI — AppIndicator talks D-Bus SNI internally
Icon caching bugs — AppIndicator caches icons by filename, causing stale icons
Not available everywhere — minimal compositors (Sway, Hyprland) don't have AppIndicator

We cut out the middleman. D-Bus SNI directly via godbus — same protocol, no GTK, no CGO.

The Numbers

Total:     ~5,800 lines of Pure Go (6,900 with docs/CI/configs)
Tests:     74 (84% public API coverage)
Platforms: Windows ✅, macOS ✅, Linux ✅
Deps:      golang.org/x/sys, go-webgpu/goffi, godbus/dbus/v5
CGO:       Zero. Absolutely zero.

Try It

go get github.com/gogpu/systray@v0.1.0

Run the example:

git clone https://github.com/gogpu/systray
cd systray/examples/basic
go run .

A green icon appears in your system tray. Right-click for the menu. Toggle dark mode to see auto-switching.

We need testers — especially on macOS and Linux (KDE, GNOME + AppIndicator extension, XFCE, Sway). File issues if something doesn't work.

Part of GoGPU

systray is standalone (go get github.com/gogpu/systray — no gogpu dependency), but it's designed to integrate with the GoGPU ecosystem — 800K+ lines of Pure Go GPU code:

Library	What It Does
wgpu	Pure Go WebGPU (Vulkan/Metal/DX12/GLES)
naga	Shader compiler (WGSL → SPIR-V/MSL/GLSL/HLSL/DXIL)
gg	2D graphics (Skia-class rasterizer)
gogpu	App framework, windowing, input
ui	GUI toolkit (22+ widgets, Material 3)
systray	System tray (this library)

All Pure Go. All zero CGO. All cross-platform. Four gogpu libraries are listed in awesome-go: systray (GUI Interaction), ui (GUI Toolkits), gg (Images), gogpu (Game Development).

If you build something with systray, let us know. Star ⭐ the repo if you find it useful — it helps others discover the project.

GoGPU - 790K Lines of Pure Go: Multi-Window GPU Apps, DXIL Compiler, and Why We Don't Need CGO

Andrey Kolkov — Tue, 28 Apr 2026 13:14:08 +0000

"Go deserves more support in GUI development"
— r/golang, October 2024

That Reddit post hit a nerve. Hundreds of upvotes, dozens of comments echoing the same frustration: Go has world-class networking, databases, and CLI tools — but when it comes to graphics and GUI, the ecosystem says "just use Electron" or "call into C."

I'd been planning a Pure Go GPU stack for years. Spent the year before that post studying exactly what to build and how — dissecting Vulkan, Metal, DX12, reading wgpu source code, analyzing Qt and Flutter architectures. That Reddit thread was the final push.

On December 5, 2025, the first window with a triangle appeared on screen. Pure Go, zero CGO, Vulkan rendering.

Less than five months later: 790K lines of Pure Go, 13 repositories, 678 GitHub stars across the ecosystem, and people building real software on it — from Quake engines to ML frameworks.

The Numbers

Repository	Description	Lines	Version
gg	2D graphics (Skia-class rasterizer)	219K	v0.43.4
naga	Shader compiler (WGSL→SPIR-V/MSL/GLSL/HLSL/DXIL)	195K	v0.17.6
ui	GUI toolkit (22+ widgets, 4 themes, 97% coverage)	171K	v0.1.14
wgpu	WebGPU implementation (Vulkan/DX12/Metal/GLES/Software)	145K	v0.26.8
gogpu	Application framework, windowing, input	50K	v0.30.0
g3d	3D rendering (scene graph, PBR, GLTF)	planned	—
compose	Jetpack Compose-style declarative UI	planned	—
systray	Cross-platform system tray	planned	—
+ 4 more	gpucontext, gputypes, gg-pdf, gg-svg	9K	—
Total	13 repos, Pure Go, zero CGO	~790K	—

790K lines of Go. 577K of that is pure code (excluding blanks and comments). 421 commits in the last two months alone.

Stars across the ecosystem:

Repo	Stars
gogpu	251
ui	211
gg	96
wgpu	87
naga	33
Total	678

How It Started

The gap between Go's server capabilities and its desktop capabilities has bothered me for years. Go has net/http that scales to millions of connections. It has database libraries that handle petabytes. But ask "how do I draw a triangle?" and you get answers involving CGO, shared libraries, or wrapping Electron in a Go process.

The existing options in 2024-2025:

Framework	Stars	Approach	The Catch
Wails	~34K	Go backend + System WebView	Not native rendering. Your "Go app" is HTML/CSS/JS with JSON IPC.
Fyne	~28K	Go + OpenGL via CGO	Requires C compiler. Custom widget look, not truly native.
Ebiten	~13K	Go + OpenGL/Metal/DX (purego)	Game engine, not a GUI toolkit. No widget system.
Cogent Core	~2.3K	Go + Vulkan via CGO (glfw)	CGO required. Large dependency tree.
Gio	~2.1K	Pure Go, immediate mode	Small widget set. Pre-1.0 API. No retained mode.

Every major framework either requires CGO or delegates rendering to a WebView. The only Pure Go option (Gio) is immediate-mode with a minimal widget set. Nothing offers native GPU rendering (Vulkan/Metal/DX12) without a C compiler.

I spent a year studying the problem:

Read Rust wgpu's source code to understand how a modern WebGPU implementation works
Studied Qt6's RHI, GTK4's GSK renderer, Flutter's Impeller to understand GUI rendering pipelines
Analyzed Vulkan, Metal, DX12, and OpenGL ES specs to map out the abstraction boundaries
Designed the layered architecture on paper before writing Go code

On December 5, 2025, the first window with a triangle appeared on screen — rendered through go-webgpu/webgpu (our Rust FFI bindings) and the gogpu framework. The Rust backend proved the architecture worked. Then, in parallel, naga (shader compiler) and wgpu (Pure Go WebGPU) began replacing the Rust dependencies one by one. Then came gg (2D graphics), and finally ui (GUI toolkit).

Multi-Window: The Feature That Changes Everything

Single-window apps are fine for demos. Real applications — IDEs, design tools, database clients — need multiple windows. We shipped multi-window support in gogpu v0.28.0, and it was the hardest architectural change we've made.

The Problem

Every major Go GUI framework (Fyne, Gio, Ebiten) either doesn't support multi-window or hacks it with separate processes. The reason is simple: GPU devices are expensive to create, but surfaces (swapchains) are per-window. You need to share one device across many windows without data races.

What We Built

We studied 7 frameworks — Qt6, GTK4, SDL3, winit, GLFW, Fyne, Gio — and wrote a 26-page Architecture Decision Record before writing a line of code.

            ┌────────────────────────────────┐
            │      Shared GPU Context        │
            │  Instance / Adapter / Device   │
            │  Queue / Pipelines / Textures  │
            └───────┬──────────┬─────────┬───┘
                    │          │         │
            ┌───────┴───┐ ┌───┴────┐ ┌──┴─────────┐
            │ Window 1  │ │Window 2│ │ Window 3   │
            │ Surface   │ │Surface │ │ Surface    │
            │ Swapchain │ │Swapch. │ │ Swapchain  │
            │ Callbacks │ │Callbk. │ │ Callbacks  │
            └───────────┘ └────────┘ └────────────┘

The API is intentionally simple:

app := gogpu.NewApp(gogpu.DefaultConfig().
    WithTitle("Main Window").
    WithSize(1200, 800))

// Second window — shares GPU device, gets its own surface
tools := app.NewWindow(gogpu.WindowConfig{
    Title: "Tool Palette",
    Width: 300, Height: 600,
})
tools.OnDraw(func(dc *gogpu.Context) {
    // dc has its own surface, shared device
})

Under the hood: PlatformManager handles process-level concerns (Win32 RegisterClass, Cocoa NSApplication, X11 Display), while each PlatformWindow manages its own message pump slice, surface, and swapchain. The WindowManager tracks all windows with monotonic WindowID — stable across window recreation, serializable for event queues. Same pattern SDL3 uses with SDL_GetNextObjectID().

VSync Strategy

Primary window runs Fifo (VSync), secondary windows run Immediate. Focus changes switch the VSync mode — the window you're looking at gets smooth frames, background windows don't waste GPU cycles. This is what Qt6 does with QRhi.

Cross-Platform

Platform	Backend	Multi-Window
Windows	Vulkan, DX12	✅ Win32 `CreateWindowEx`
macOS	Metal	✅ Cocoa `NSWindow`
Linux X11	Vulkan	✅ `XCreateWindow`
Linux Wayland	Vulkan	✅ `xdg_toplevel`

All 4 platforms support multi-window with shared GPU device. EventFocus events route correctly across windows on all platforms.

Event-Driven Frame Pacing

Enterprise GUI frameworks don't render on every OS event. They render only when something visual actually changed. Our render loop had a shortcut:

if continuous || invalidated || hasEvents {
    renderFrame()
}

That hasEvents flag meant every mouse move, every platform event triggered a full render cycle — even when nothing on screen changed. Moving the mouse over a static window caused unnecessary GPU work on every frame.

We researched 6 frameworks (winit, Gio, Qt6, Flutter, SDL3, Ebiten) and found they all use the same pattern: handlers decide when to invalidate, the render loop never guesses.

Now in v0.30.0:

if continuous || invalidated {
    renderFrame()
}

Resize and focus events call RequestRedraw() explicitly. Mouse events reach the UI framework, which calls RequestRedraw() only when a widget's visual state actually changes.

Mouse move over static UI: 0% GPU. Hover over a button: UI calls RequestRedraw(), one frame renders. Exactly how winit and Flutter work.

The First Pure Go DXIL Generator

We wrote about this in detail, but here's the update: naga's DXIL backend now passes 94/208 DXC golden tests (45% parity with Microsoft's own compiler). The IDxcValidator pass rate is 161/170 (94.7%).

This matters because Rust naga — the reference implementation maintained by Mozilla — still doesn't have a DXIL backend. There's been an open issue since 2020. Six years later, still not implemented.

We did it in Pure Go. No LLVM, no external tools. Direct DXIL bitcode generation from our shader IR.

Yes, we know Microsoft is adding SPIR-V support to DirectX 12 in a future SDK update. But DXIL is the native DX12 shader format today, and having a direct DXIL generator means we don't depend on external toolchains or wait for Microsoft's timeline.

How the Shader Pipeline Works

WGSL source code
      ↓  (naga lexer + parser)
   naga IR (typed, validated)
      ↓  (backend selection)
  ┌───┴───┬────┬─────┬──────┐
  SPIR-V  MSL  GLSL  HLSL  DXIL
  (Vulkan)(Metal)(GLES)(DX11)(DX12)

All 5 backends generate from the same IR. 330+ tests. The DXIL backend includes single-store local promotion, strength reduction, fragment signature ordering, and dead code elimination — real compiler passes, not string templating.

gogpu/ui: A Real GUI Toolkit

Most Go GUI toolkits ship a handful of basic controls and call it done. We're building something closer to Qt or Flutter — a complete widget system with theming, accessibility, and enterprise-grade architecture.

22+ widgets shipping today:

Category	Widgets
Input	TextField, TextArea (multi-line), Checkbox, Radio, Switch, Slider, Dropdown
Display	Label, Image, Icon, ProgressBar, Badge, Chip, Divider, Card
Navigation	Button, IconButton, FAB, AppBar, TabBar
Layout	Column, Row, Stack, ListView, ScrollView, GridView
Overlay	Dialog, Snackbar, Tooltip, BottomSheet, PopupMenu
Advanced	TreeView, DataTable, SplitView, Docking, Menu, Toolbar

4 design systems: Material Design 3, DevTools (JetBrains), Fluent (Microsoft), Cupertino (Apple). Full token-based theming — change every color, radius, elevation, font in one struct.

171K LOC | 55+ packages | 6,803 tests | 97%+ average coverage.

Signal-Driven Retained-Mode Compositor (ADR-007)

The latest v0.1.14 shipped the biggest architectural change in ui: a signal-driven retained-mode compositor that replaced the legacy hybrid pipeline.

The old pipeline had a fundamental conflict: CPU pixmap was retained (persistent between frames), but GPU shapes (shadows, rounded corners) were ephemeral (re-queued every frame). On frames where nothing changed, GPU shapes disappeared — visible flicker.

ADR-007 unified everything into a scene graph:

Widget tree
    ↓  SetNeedsRedraw() (per-widget dirty flag)
Scene.Encoding (compact display list: 9-25 bytes/command)
    ↓  RepaintBoundary (cached scene per subtree)
scene.Renderer (auto GPU/CPU selection, 64×64 tile grid)
    ↓  FlushGPUWithView (single render pass → swapchain)

Every widget records into a scene.Scene display list instead of drawing to a pixmap. RepaintBoundary caches scene encodings per subtree — when a spinner animates, only its 48×48 tile re-renders, not the full window. Reactive signals (coregx/signals) trigger SetNeedsRedraw() on exactly the widgets that changed.

Results:

Taskmanager example GPU: 7-18% → 0-1%
IDE hover lag: eliminated
Gallery flickering: fixed
Full DrawTree via GPU pipeline every frame — no retained CPU pixmap

This is still a work in progress. Complex animated widgets like classic spinners need additional optimization — the present path still does a full-surface render pass even when only a 48×48 pixel region changed. Damage-rect passthrough and sub-region compositing are the next steps.

More Architecture

Reactive state via signals (Signal, Computed, Effect, Binding)
GPU-accelerated rendering via gg → wgpu
Granular widget invalidation — 11 widgets use SetNeedsRedraw + InvalidateRect instead of full-surface redraw
Accessibility from day one: 35+ ARIA roles, screen reader announcer
Full i18n: CLDR plural rules, RTL detection

What's Coming Next

g3d — 3D Rendering Library

gogpu/g3d is the Three.js of Go. Scene graph, PBR materials (metallic-roughness), GLTF 2.0 loading, directional/point/spot lights, frustum culling, instance batching. Built on wgpu, not OpenGL.

scene := g3d.NewScene()
cube := g3d.NewMesh(
    g3d.NewBoxGeometry(1, 1, 1),
    g3d.NewStandardMaterial(),
)
scene.Add(cube)
renderer.Render(scene, camera)

compose — Declarative UI

gogpu/compose brings Jetpack Compose-style declarative UI to Go. Composable functions, automatic recomposition on state change, slot-based layout. Transport-pluggable architecture — same composable code can render to GPU window, headless image, or remote display.

systray — System Tray

gogpu/systray — cross-platform system tray icons. Win32 Notification Area, macOS Menu Bar Extra, Linux StatusNotifierItem/AppIndicator. Multiple trays, nested menus, notifications, dark mode icon switching. Pure Go, zero CGO.

Browser Target (WASM + WebGPU)

wgpu already has the build infrastructure for WASM (platform split shipped in v0.25.5). The plan: compile to WASM, use browser's native WebGPU API via syscall/js. Same app code, same shaders, runs in Chrome. Phase 0 complete, Phase 1 (navigator.gpu binding) is next.

Android Support

Under active discussion. The architecture is ready — wgpu's Vulkan backend works, naga generates SPIR-V, gogpu's PlatformManager/PlatformWindow abstraction was designed with mobile in mind. What remains: NativeActivity or GameActivity integration, touch input, lifecycle management (suspend/resume), and the build pipeline (gomobile or direct NDK).

ui — Major Overhaul Coming

The GUI toolkit is getting substantial improvements. The ADR-007 retained-mode compositor was just the beginning — next up is the full scene-graph pipeline where every widget records into display lists instead of immediate-mode drawing. More widgets, better performance, production-ready accessibility. The goal: a Go GUI toolkit that you'd actually choose over Electron for a desktop app.

Real Users, Real Software

This isn't a toy. People are building on GoGPU:

ironwail-go by @darkliquid — a Quake 1 engine port running on gogpu/wgpu Vulkan on Wayland+niri. The first 3D game on a Pure Go GPU stack. Demo video on the project README.
Born ML — our ML framework, migrating from Rust FFI (go-webgpu/webgpu) to gogpu/wgpu. Single-binary deployment, DXIL backend for DX12 compute — things the Rust FFI path couldn't provide.
L-System fractals by @rcarlier — 47 million points rendered via gg, running in WASM and CLI. "Amazing performance!"
@jdbann — contributing Metal backend fixes, testing on M4 Pro MacBook.
@SideFx — testing on Adreno mobile GPUs, helping us find driver-specific bugs.

The Architecture That Makes It Work

The secret is layered independence. Each layer does one thing, doesn't know about layers above it, and can be used standalone:

User Application
      │
  ┌───┴────┬──────┬────────┐
  gogpu/ui  gogpu  gg  g3d    ← Application layer
  ├────────┘  │    │    │
  gpucontext ─┘    │    │     ← Shared interfaces
  │                │    │
  wgpu ────────────┘────┘     ← WebGPU implementation
  │
  naga                        ← Shader compiler

gogpu — The Windowing & Application Framework

gogpu/gogpu (~50K lines) is the foundation everything else builds on. Think of it as SDL or GLFW — but Pure Go, with a WebGPU renderer built in.

What it provides:

Cross-platform windowing — Win32, Cocoa (AppKit), X11, Wayland. Pure Go, no CGO. All 4 platforms implemented from scratch using our goffi FFI library (syscall-level, no C compiler).
GPU lifecycle — Instance → Adapter → Device → Queue → Surface. Dual backend: Pure Go (gogpu/wgpu) or Rust FFI (go-webgpu/webgpu). Backend selected at build time or runtime.
Multi-window — shared GPU device, per-window swapchain, monotonic WindowID, focus-aware VSync (ADR-010).
Event system — keyboard, mouse, touch (X11 XInput2), gestures, Unicode text input (IME) on all platforms.
Multi-thread architecture — main thread for window events (keeps the OS happy), render thread for all GPU operations (keeps the GPU fed). Modal resize/drag on Windows handled via WM_TIMER callback.
HiDPI/Retina — per-monitor DPI, logical/physical coordinate split, WM_DPICHANGED on Windows.
Frameless windows — custom title bars with DWM shadow, hit-test regions (JetBrains Runtime pattern).
Mouse grab / pointer lock — locked, confined, normal modes (SDL parity) on Win32, X11, Wayland.
Software backend — always available, renders to GDI (Windows), XPutImage (X11), CALayer (macOS). No GPU required.

The App implements DeviceProvider — any library that accepts a gpucontext.DeviceProvider can use gogpu's GPU device without importing gogpu directly.

The Other Layers

naga (~195K lines) — shader compiler. WGSL in, SPIR-V/MSL/GLSL/HLSL/DXIL out. Used by wgpu at pipeline creation time.

wgpu (~145K lines) — Pure Go WebGPU implementation. 5 HAL backends (Vulkan, DX12, Metal, GLES, Software). Resource lifecycle, validation, state tracking. The layer between your draw calls and the GPU driver.

gg (~219K lines) — 2D graphics. Skia-class analytic AA rasterizer, Vello-derived tile rasterizer, GPU SDF accelerator, text rendering, SVG, alpha masks. Can work standalone (no window) or with gogpu's GPU device.

gpucontext (~3.6K lines) — the glue. Depends only on gputypes. Defines DeviceProvider, TextureView, CommandEncoder — interfaces that let all packages share GPU resources without circular imports. The database/sql of GPU programming.

Every layer can be used independently:

gg without gogpu — 2D graphics without windowing
wgpu without gg — raw WebGPU for compute or custom rendering
naga without anything — shader compilation as a library

What We Learned

1. Research before code. Every major feature starts with an Architecture Decision Record studying 5-8 enterprise implementations. The multi-window ADR studied Qt6, GTK4, SDL3, winit, GLFW, Fyne, and Gio before a line of code was written. This saved weeks of wrong turns.

2. CPU is core, GPU is accelerator. We analyzed 8 enterprise 2D engines (Skia, Cairo, Vello, Blend2D, tiny-skia, piet, Qt RHI, Pathfinder) and found that in zero of them is CPU rasterization a "backend." It's always the core. GPU accelerates specific operations. This insight shaped gg's entire architecture.

3. Zero CGO is a real competitive advantage. With the Rust FFI backend, every platform needed its own wgpu_native.dll/.so/.dylib — find it, download it, put it in the right place, hope the versions match. With Pure Go wgpu: go build and it works. No shared libraries to hunt for, no linker errors, no "works on my machine." Cross-compilation just works.

4. Enterprise references prevent enterprise bugs. When we tried to add DX12 texture barriers without studying how Rust wgpu handles them, we got TDR crashes at frame 575. When we studied the reference first, we found the root cause in 10 minutes.

5. Small teams win through focus. Our naga DXIL backend shipped before Rust naga's (open issue since 2020). Not because of more resources — because of fewer coordination costs and a clear research → design → implement pipeline. Architectural decisions compound: choosing WebGPU as the abstraction meant our Metal backend was ready when Apple deprecated OpenGL, and our shader IR was ready when DX12 needed DXIL.

Try It

# Install
go get github.com/gogpu/gogpu

# Run the particles demo (compute + render, zero CGO)
CGO_ENABLED=0 go run github.com/gogpu/gogpu/examples/particles@latest

# Run the multi-window demo
CGO_ENABLED=0 go run github.com/gogpu/gogpu/examples/multiwindow@latest

Requirements: Go 1.25+, a GPU with Vulkan/DX12/Metal/GLES support (or use Software backend for headless).

Links

Resource	URL
GitHub Organization	github.com/gogpu
Main Repository	github.com/gogpu/gogpu
GUI Toolkit	github.com/gogpu/ui
2D Graphics	github.com/gogpu/gg
3D Library	github.com/gogpu/g3d
Shader Compiler	github.com/gogpu/naga
Previous: DXIL Article	dev.to/kolkov/dxil
Previous: 100K LOC Article	dev.to/kolkov/100k
Smart Coding Methodology	dev.to/kolkov/smart-coding

The Core Is Stable — Now We Need You

The foundational libraries — wgpu, naga, gg, gogpu — have reached a level of stability where the focus is shifting. The WebGPU implementation handles Vulkan, DX12, Metal, GLES, and Software. The shader compiler generates 5 output formats. The 2D rasterizer passes thousands of tests. The windowing framework runs on 4 platforms with multi-window support.

Now the main effort goes into ui (the GUI toolkit), new ecosystem libraries (g3d, compose, systray), and the Browser backend (WASM + WebGPU — same app code running in Chrome). This is where things get exciting, and this is where we need feedback.

Try it. Break it. Tell us what's missing.

Found a bug? Open an issue — we respond fast.
Built something with GoGPU? Share it — we love showcasing community projects.
Want to write about it? Articles and video reviews help the ecosystem grow more than anything else.
Have ideas for the UI toolkit? Join the discussions.

Go deserves a real graphics ecosystem. We're building it — and it's ready for you to start building on.

We Built the First Pure Go DXIL Generator — Because Optimizing the Wrong Path Wasn't Enough

Andrey Kolkov — Sun, 05 Apr 2026 23:00:53 +0000

"Go doesn't have a real graphics ecosystem." — We've heard this for years. So we built one: 636K lines of Pure Go, five GPU backends, zero CGO. And now we've done something that even Rust's naga shader compiler hasn't managed in six years.

At the end of last year, we introduced GoGPU to the Go community — greeting everyone with a New Year's gift: a professional graphics ecosystem written entirely in Go. Four months later, that ecosystem just got its most audacious component: a Pure Go DXIL generator that compiles shaders directly to DirectX 12 bytecode, without any external compiler.

This is the story of how a performance optimization rabbit hole led us to write our own LLVM 3.7 bitcode emitter.

The Problem That Wouldn't Go Away

Every DirectX 12 application needs compiled shaders. The standard pipeline looks like this:

WGSL → HLSL text → FXC (d3dcompiler_47.dll) → DXBC bytecode → GPU

That middle step — d3dcompiler_47.dll — is a 4.3 MB Microsoft DLL that you load at runtime. It works. It's battle-tested. And it was our bottleneck.

We build gogpu — a Pure Go GPU ecosystem with its own shader compiler, naga. Four backend outputs already at 100% Rust naga parity. Everything compiles with go build, no C toolchain needed.

But on Windows with DirectX 12, we had a dirty secret: d3dcompiler_47.dll. The one external dependency in our otherwise dependency-free stack.

The Optimization Rabbit Hole

We tried everything to make the FXC path fast enough to forget about:

Shader cache — Hash the HLSL, cache the DXBC. First render is slow, subsequent ones instant. Works great until your shader variants explode.

In-memory compilation pool — Pre-compile common shaders at startup. Reduces cold-start latency. But we still load the DLL.

Pipeline State Object caching — We planned disk caching of PSO blobs (GetCachedBlob → os.UserCacheDir()). We wrote the task, designed the key format, specified the invalidation strategy. Then we never shipped it — because we pivoted to eliminating FXC entirely.

naga HLSL fix — FXC was choking on naga-generated HLSL: a (Type[256])0 bulk zero-initialization expanded to a 12KB inline constructor that FXC took 22 seconds to compile. We initially thought our Go naga had a bug, so we tested the same shader through Rust naga + FXC — same 22 seconds. It wasn't our implementation; FXC genuinely can't handle giant inline constructors. The fix was in naga (per-element loop instead of inline constructor, v0.16.3) — 330× faster. But even after fixing the worst case, every shader still went through an external DLL.

Every optimization made the same path faster. None of them removed the path.

At this point we had a decision to make. The obvious next step was adding DXC (dxcompiler.dll) as an opt-in replacement for FXC — newer, faster, supports Shader Model 6.0+. We even created the task for it.

Then, while reviewing the plan, a simple question came up: "Can we write our own DXC in Go?"

The initial answer was: "No. DXC is 500K lines of C++, a fork of LLVM 3.7. That's not something you casually rewrite."

The response: "Not rewrite DXC. Generate DXIL directly. Skip HLSL entirely."

That changed everything. DXC takes HLSL text and produces DXIL. We already have our own IR (naga IR). Why translate IR → HLSL text → parse HLSL → produce DXIL, when we could go IR → DXIL directly?

DXC is a compiler from one language (HLSL) to another (DXIL). We don't need a compiler — we need an emitter. And emitting is much simpler than compiling.

What is DXIL, and Why Nobody Writes It

DXIL (DirectX Intermediate Language) is what FXC and DXC produce. It's LLVM 3.7 bitcode — the same IR format that LLVM uses internally — wrapped in a DXBC container with DirectX-specific metadata and dx.op intrinsic calls.

The reason nobody writes DXIL directly is simple: it's hard.

LLVM 3.7 bitcode is a binary format with variable-width encoding (VBR), nested blocks, abbreviation records, and forward references. Not something you casually emit.
DXIL semantics require dx.op intrinsic calls instead of normal LLVM instructions for I/O, math, and resource access. 165+ opcodes.
DXBC container needs input/output signatures (ISG1/OSG1), pipeline state validation (PSV0), feature flags (SFI0), and a cryptographic hash.
Validation — until January 2025, every DXIL module needed to be signed by dxil.dll. Microsoft's BYPASS hash sentinel changed this.

Rust's naga shader compiler has had an open issue for DXIL backend since 2020. Six years later, it's still not implemented.

Only one project has done it outside of LLVM: Mesa (the open-source OpenGL/Vulkan driver stack). Their DXIL compiler is ~21,000 lines of C/H, written by engineers from Microsoft and Collabora over 3+ years. They wrote their own LLVM 3.7 bitcode writer from scratch — proving it's possible without linking LLVM.

We cloned Mesa's src/microsoft/compiler/ into our reference folder, studied dxil_module.c (the bitcode writer, ~3K lines of C), and mapped out every block type, record format, and abbreviation. Not to copy — to understand the format deeply enough to write our own.

Then came the final piece: in January 2025, Microsoft open-sourced the DXIL validator hash and introduced a BYPASS sentinel — a magic value in the hash field that tells D3D12 "this shader wasn't signed by dxil.dll, but trust it anyway." Without this, our DXIL wouldn't run without Developer Mode on Windows. With it, any third-party DXIL generator can produce shaders that run on retail Windows.

We weren't afraid of binary formats. Before gogpu, we built scigolib/hdf5 — a Pure Go implementation of HDF5, NASA's hierarchical data format with its own B-tree indices, chunked storage, and compression pipelines. After parsing HDF5 superblocks and fractal heaps in pure Go, LLVM bitcode felt almost... reasonable. We also built coregx/coregex — a multi-engine regex system (17 strategies, Lazy DFA, PikeVM, SIMD prefilters) that runs up to 3000× faster than Go's stdlib. Complex binary formats and low-level encoding are kind of our thing.

We spent weeks studying the DXIL format specifically. Reading the DXIL spec, the LLVM 3.7 bitcode reference, Mesa's implementation, Microsoft's DXC headers, the validator hash proposal. We wrote a detailed architecture document comparing four implementation options. We mapped every dx.op opcode we'd need for vertex and fragment shaders. We designed the package structure, the phased rollout plan, the testing strategy.

Only after all that research did we write the first line of code.

Building LLVM 3.7 Bitcode in Pure Go

The first challenge was the bitcode writer. LLVM 3.7's format is... unique:

Bits, not bytes. Variable-width encoding. Nested blocks with
forward-declared sizes. Abbreviation records that compress
common patterns. A module structure that interleaves types,
constants, functions, and metadata in a specific order.

We wrote a bit-level writer from scratch:

// VBR (Variable Bit Rate) encoding — like protobuf varint, but bit-aligned
func (w *Writer) WriteVBR(value uint64, width uint) {
    tag := uint32(1) << (width - 1)
    mask := tag - 1
    for value > uint64(mask) {
        chunk := uint32(value&uint64(mask)) | tag
        value >>= width - 1
        w.WriteBits(chunk, width)
    }
    w.WriteBits(uint32(value), width)
}

Then the module serializer: TYPE_BLOCK, CONSTANTS_BLOCK, FUNCTION_BLOCK, METADATA_BLOCK — each with its own record formats, abbreviation IDs, and ordering constraints.

The DXBC container assembles the bitcode with signatures and metadata:

[DXBC Header]           32 bytes (magic + digest + version + size + part count)
  [SFI0]                Shader feature flags (64-bit bitmask)
  [DXIL]                Program header + LLVM 3.7 bitcode
  [ISG1]                Input signature (semantic names, registers)
  [OSG1]                Output signature
  [PSV0]                Pipeline state validation
  [HASH]                BYPASS sentinel (no dxil.dll needed!)

The DXIL Difference: Scalarized Vectors

Here's something that makes DXIL fundamentally different from SPIR-V, MSL, GLSL, and HLSL: DXIL has no native vector types.

In SPIR-V, you write OpCompositeConstruct %vec4 %x %y %z %w.
In HLSL, you write float4(x, y, z, w).
In DXIL, there are no vectors. A vec4<f32> becomes four separate float values, tracked independently through every operation.

// Our emitter tracks per-component value IDs
type Emitter struct {
    exprValues     map[ir.ExpressionHandle]int    // scalar value IDs
    exprComponents map[ir.ExpressionHandle][]int  // per-component IDs for vectors
}

// dot(a, b) becomes:
// %r = call float @dx.op.dot3.f32(i32 55, float %ax, float %ay, float %az,
//                                          float %bx, float %by, float %bz)

This means every vector operation — dot product, cross product, normalize, swizzle — must be decomposed into scalar operations. Our existing backends (SPIR-V, MSL, GLSL, HLSL) all work with native vectors. DXIL required a completely different approach.

Cross product becomes 6 multiplies and 3 subtracts:

// cross(a, b) = vec3(a.y*b.z - a.z*b.y, a.z*b.x - a.x*b.z, a.x*b.y - a.y*b.x)
cx := fsub(fmul(ay, bz), fmul(az, by))
cy := fsub(fmul(az, bx), fmul(ax, bz))
cz := fsub(fmul(ax, by), fmul(ay, bx))

Control Flow: Basic Blocks, Not Nesting

Another fundamental difference: DXIL uses LLVM-style basic blocks with explicit branches, not the nested text structure of HLSL/GLSL/MSL.

Our text backends emit:

if (cond) {
    // accept
} else {
    // reject
}

DXIL emits:

entry:
  br i1 %cond, label %then, label %else
then:
  ; accept statements
  br label %merge
else:
  ; reject statements
  br label %merge
merge:
  ; continues

Loops use back-edge branches to a header block. Break and continue jump to specific target blocks tracked via a loop context stack.

We studied Mesa's nir_to_dxil.c for the correct patterns, then cross-referenced with our own SPIR-V backend (which also uses structured control flow with merge blocks) to get the Go implementation right.

What Our Backends Taught Us

This is the part that surprised us most. We have four mature backends (SPIR-V, MSL, GLSL, HLSL) totaling ~68K LOC. They all solve the same IR walking problems:

Expression dispatch and caching
Type resolution through pointer chains
Statement nesting and control flow
Resource binding and I/O handling

Before implementing each DXIL feature, we checked how our existing backends handled it:

Feature	We checked	What we learned
Multi-arg math	HLSL `writeExpressionKind`	Arg/Arg1/Arg2/Arg3 dispatch pattern
Type casts	SPIR-V `emitAs`	src/dst kind+width → opcode selection
Control flow	HLSL `writeIfStatement`	Condition, blocks, merge point structure
Store/Load	SPIR-V `emitStore`	Pointer chain resolution
Struct access	MSL `writeAccessChain`	Recursive descent through members

The DXIL backend is different (scalarized, basic blocks, dx.op intrinsics), but the IR patterns are the same. Our existing codebase was its own best reference.

The Moment of Truth

After all the research, all the planning, all the implementation — ~12,500 lines of Go code, 190 tests, weeks of work — came the moment that mattered:

GOGPU_DX12_DXIL=1 GOGPU_GRAPHICS_API=dx12 go run ./cmd/wgpu-triangle

The terminal showed:

wgpu API Triangle Test
Adapter: Intel(R) Iris(R) Xe Graphics
dx12: using DXIL direct compilation (naga dxil backend)
Render loop started
Frame 60 (64.6 FPS)
Frame 120 (62.1 FPS)
...
Frame 2400 (59.9 FPS)

A red triangle on a blue background. The most boring demo in graphics programming. And the most satisfying.

WGSL → naga.Parse → naga.Lower → IR → dxil.Compile → DXIL → D3D12 → GPU
         Pure Go      Pure Go          Pure Go

2,400+ frames. 60 FPS. Stable. On Intel Iris Xe, DirectX 12. No DLL loaded, no subprocess spawned. Just Go code producing bytes that a GPU executes.

By the Numbers

Metric	Value
Total DXIL code	~12,500 lines (9,400 code)
Test count	190
New files	26
Public API surface	4 types (`Compile`, `DefaultOptions`, `Options`, `ShaderModel`)
External dependencies	0
CGO calls	0
CI platforms	macOS + Ubuntu + Windows (all green)
Time to first frame	Instant (no subprocess)

For comparison, Mesa's DXIL compiler is ~21,000 LOC of C/H, built by engineers from Microsoft and Collabora over three years. We owe them a debt — their bitcode writer was our Rosetta Stone for understanding the format. But Go isn't C, and naga IR isn't NIR, so the actual code is written from scratch.

What's Experimental (and What's Next)

This is v0.17.0 with an (experimental) label. Here's what works and what doesn't:

Works now:

Vertex + fragment shaders
All arithmetic, comparison, logical operations
30+ math intrinsics (min, max, clamp, dot, cross, mix, fma, length, normalize...)
Type casts (10 LLVM cast opcodes)
Control flow (if/else, loops, break/continue)
Local variables (alloca + load + store)
Texture sampling
Resource handle creation (CBV/SRV/Sampler)
I/O signatures and pipeline state validation

Coming next:

Compute shaders (UAV, atomics, barriers)
Uniform buffer reads (cbufferLoadLegacy wiring)
SM 6.1-6.9 features (wave intrinsics, mesh shaders)

The experimental label means: it renders triangles today, but don't ship a game with it tomorrow.

The Bigger Picture

naga is part of GoGPU — a 636K LOC Pure Go GPU ecosystem:

Project	LOC	What
gg	153K	2D graphics, GPU SDF, SVG renderer
naga	145K	Shader compiler (now with DXIL!)
wgpu	134K	Pure Go WebGPU (Vulkan/DX12/Metal/GLES)
ui	121K	GUI toolkit, 22+ widgets, 4 themes
gogpu	39K	Application framework

With DXIL, gogpu/naga has surpassed Rust naga in backend coverage:

Backend	Go naga	Rust naga
SPIR-V	100% (87/87 golden, 164/164 spirv-val)	100%
MSL	100% (91/91)	100%
GLSL	100% (68/68)	100%
HLSL	100% (72/72)	100%
DXIL	Experimental (working)	Not implemented (open issue since 2020)

What started as a compatibility effort is now something more.

Try It

go get github.com/gogpu/naga@v0.17.0

import "github.com/gogpu/naga/dxil"

// Parse WGSL, lower to IR, compile to DXIL
ast, _ := naga.Parse(wgslSource)
module, _ := naga.Lower(ast)
dxilBytes, _ := dxil.Compile(module, dxil.DefaultOptions())

// dxilBytes is a complete DXBC container — feed directly to D3D12

Repository: github.com/gogpu/naga
Release: v0.17.0

Previously in this series:

We Reverse-Engineered 12 Versions of Claude Code. Then It Leaked Its Own Source Code.

Andrey Kolkov — Tue, 31 Mar 2026 15:21:11 +0000

Updated April 1, 2026: Posted complete fix proposal with source references (#41981) — immediate fixes, SDK restructuring, ping-aware adaptive watchdog, Go rewrite rationale with production-ready library stack. Validated all claims against leaked source code (line numbers). v2.1.89 released — source map removed, zero bug fixes for any streaming issues.

"Thank you, Claude Code. We asked humans for help 17 times. You answered in 3 days."

This is a story about frustration, reverse engineering, and an AI tool that may have leaked its own source code because its creators wouldn't listen.

Chapter 1: The Pain (August 2025 — February 2026)

I'm a software developer building enterprise-grade open source in Go. 40+ public repos on GitHub. My projects include:

GoGPU — Pure Go GPU computing ecosystem: WebGPU implementation, WGSL shader compiler (SPIR-V/MSL/GLSL/HLSL), enterprise 2D graphics, GUI toolkit. 680K+ lines of Go, zero CGO. Vulkan, Metal, GLES, DX12 backends.
coregex — Regex engine 3-3000× faster than Go stdlib. 17 matching strategies, SIMD acceleration, LazyDFA, PikeVM. Drop-in regexp replacement.
Born — Production-ready ML framework in pure Go. Type-safe tensors, automatic differentiation, GPU via WebGPU (123× MatMul speedup), ONNX/GGUF import. Neural networks as single Go binaries.
coregx — Suite of production-grade Go libraries: HTTP router, SQL builder, PDF generation, pub/sub messaging. All zero CGO, minimal dependencies.

I also build multi-LLM tooling — my own private ecosystem called PupSeek that works with multiple AI providers. I've tested them all.

Anthropic's Opus models are the best for coding. Nothing else comes close. But Opus 4.6 via API costs $5/$25 per MTok (input/output), fast mode is $30/$150 — and a heavy coding session with 1M context easily burns $50-100/day. So you're forced into Claude Max subscription ($100-200/month) — which means using Claude Code, their CLI wrapper. There's no alternative: the best model locked behind a buggy tool.

It started small. A hang here, a timeout there. Press ESC, retry, move on. "They'll fix it soon," I told myself. "The product is new."

Months passed. The hangs got worse. The community was screaming: #6836 — 150+ reports of orphaned tool calls. #26224 — agent hangs 5-20 minutes. #20171 — phantom "Generating..." state, 0 tokens. All open, no official response.

Then came March 2026:

March 15: Complete system deadlock. Keyboard dead. Only a hard power-off saved me. (Related: #30137, #32870 — Windows BSODs)
March 17: Bun runtime crash. 13.81 GB memory leak. 12-hour overnight session — lost. (Our issue: #35171)
March 19: Another Bun crash. 15.40 GB committed memory. 23.7-hour session gone. (Our issue: #36132)

Three crashes in five days. I was spending more time babysitting the tool than coding. And I was paying for this.

That's when I stopped hoping and started digging.

Chapter 2: Reverse Engineering (March 13 — March 27)

Claude Code ships as a single minified cli.js — 12 MB of compressed JavaScript on one line. No source maps. No comments. Variables renamed to X6, K8, b6.

I downloaded it with npm pack @anthropic-ai/claude-code and started grepping.

The tools

# This is what "reverse engineering" looks like when you're desperate:
sed -n '7682p' cli.js | tr ';' '\n' | grep "for await"

Each "line" of the minified file is 10,000–25,000 characters. To trace a code path, I'd:

Find a string constant (CLAUDE_STREAM_IDLE_TIMEOUT_MS)
Get the line number (grep -n)
Split by semicolons (tr ';' '\n')
Count brace depth to determine scoping (node -e script counting { and })
Map variable names between versions (they change on every build)

I did this for 12 versions (v2.1.74 through v2.1.88). Built a Go CLI tool (ccdiag) to analyze session JSONL files. Analyzed 1,571 sessions, 148,444 tool calls.

What I found

5.4% of all tool calls were orphaned — the model asked for a tool, the tool ran, but the result never made it back. Silently dropped.

I published the streaming hang root cause analysis as #33949 (👍15, 27 comments). Also reported the .claude.json storage architecture problem in #5024 (👍47) — 3.1 GB of unmanaged flat files with inconsistent file locking.

But that was just the beginning.

Chapter 3: The Watchdog That Doesn't Watch (March 27)

Deep in the minified code, I found a streaming idle watchdog — CLAUDE_ENABLE_STREAM_WATCHDOG. It's disabled by default, hidden behind an undocumented environment variable. I enabled it and... the hangs reduced significantly.

But then I traced the full error path and found three compounding bugs:

Bug 1: The watchdog initializes too late

do {
    e = await generator.next()   // ← CAN HANG HERE!
} while (!e.done)                //   WATCHDOG NOT ARMED YET!

// Watchdog initializes HERE — AFTER the dangerous phase:
resetStreamIdleTimer()

The watchdog protects the SSE event loop but not the initial connection phase — which is where 100% of our observed hangs occur.

Bug 2: The abort function does nothing

When the watchdog fires, it calls releaseStreamResources() which tries to abort stream and streamResponse. But during the initial connection phase, both are undefined. The abort is literally a no-op.

Bug 3: The non-streaming fallback doesn't work where it matters

There's fallback code with telemetry (fallback_cause: "watchdog") that switches to a non-streaming request when the watchdog fires. It actually works — but only when the hang occurs during SSE event processing (for-await phase), because releaseStreamResources() can abort the active stream.

During the initial connection phase (do-while) — where 100% of our observed hangs occur — stream and streamResponse are both undefined. The abort is a no-op. The fallback never triggers.

So the fallback works in the phase that rarely hangs, and doesn't work in the phase that always hangs. The watchdog feature has been in the codebase for 5+ months without protecting the most vulnerable code path.

We could only figure this out from the readable source code — in the minified version, we initially thought the fallback was completely dead code (#39755). The source revealed it's more nuanced: the architecture is partially correct but fails exactly where it's needed most. This is precisely why we begged for source access — reverse engineering 12 MB of minified JavaScript gives you the broad strokes, but the subtle interactions between releaseStreamResources(), stream = undefined, and the AbortError catch chain only become clear in readable TypeScript with comments.

I filed issue #39755 with full analysis, code paths, and suggested fixes. Tagged 17 Anthropic team members.

The bot labeled it bug, has repro, area:core. No human responded.

Chapter 4: The Patch (March 30)

I patched cli.js — moved the watchdog initialization before the do-while loop. One line moved. Zero bytes size change.

Results from a real session (naga shader compiler project):

Metric	Before Patch (6 hours)	After Patch (2.5 hours)
Watchdog warnings	0	5 (first time ever!)
Watchdog timeouts	0	3 (automatic recovery!)
ESC aborts needed	21 (3.5/hour)	1 (0.4/hour)

ESC aborts dropped 8.7×. The watchdog was finally firing in the phase that needed it most.

But recovery was slow — 3.5 minutes between abort and retry. Because Bug 2: the abort function targets undefined variables in the do-while phase.

Chapter 5: 16.3% Failure Rate (March 25-31)

Over 6 days, one session made 3,539 API requests. The failure breakdown:

Type	Count	%
529 Server Overloaded	328	9.3%
ESC Aborts (manual)	157	4.4%
Watchdog Timeouts	45	1.3%
Non-streaming Fallbacks	46	1.3%
Total Failures	576	16.3%

Every 6th request fails. On a paid Max plan. Every failure = lost context, lost time, frustrated developer pressing ESC.

The issue counts on GitHub — 15 upvotes here, 150 there — don't reflect the true scale. Most users never report because they think this is normal. "The model is thinking" — no, the connection is dead. "It's slow today" — no, the watchdog didn't fire and you're staring at a hung socket. "My limits ran out fast" — no, the attestation bug broke your prompt cache. Users blame the model, blame their internet, blame peak hours — because Claude Code gives them zero feedback about what's actually happening. Silent fallbacks, silent retries, silent downgrades. You can't report a bug you don't know exists.

Chapter 6: "Please Open Source It" (March 27)

In issue #39755, I included a section: "Why open-sourcing Claude Code makes business sense in 2026."

The arguments:

Revenue comes from API access, not CLI sales
The "secret" is already recoverable (npm pack + a weekend)
Bugs sit undiscovered for months in 12 MB minified code
The community is already doing the work — give us readable source and we'll find bugs 10× faster

I tagged the entire Claude Code team. 17 people.

Zero responses from Anthropic. As usual.

At that point I had a suspicion: maybe Anthropic can't open source Claude Code — not because of competitive advantage (there is none — it's a CLI wrapper), but because the code quality is so poor that publishing it would be embarrassing. Bug on top of bug, workaround on top of workaround, zero tests. You don't open source something you're ashamed of.

Three days later, the source map leak proved me right.

Chapter 7: The Leak (March 31)

Three days after my open source request, Claude Code v2.1.88 was published to npm with a 59.7 MB source map file bundled in.

The entire source code of Claude Code — 1,884 TypeScript files, 64,464 lines — sitting in plain sight in the npm package. Bun generates source maps by default. Nobody turned it off. Nobody checked what was in the published package.

Zero tests. On 64,464 lines of production code serving paying customers.

Within hours: 1,100+ stars on GitHub mirrors, Hacker News front page, Chinese dev communities creating WeChat groups and working forks.

Anthropic unpublished v2.1.88 from npm and rolled back to v2.1.87 within the day. But the source was already everywhere.

Chapter 8: What We Found in the Source

Everything our reverse engineering discovered was confirmed. Plus new findings:

The Sentiment Detector

// An AI company with the world's best language model
// uses REGEX to detect user frustration:
/\b(wtf|shit|fuck|horrible|awful|terrible)\b/i

As a Hacker News commenter noted: "A company offering master's degrees in humanities is using regex for sentiment analysis? It's like a trucking company using horses to transport spare parts."

The Attestation Bug (cch=00000)

The native Bun installer includes a Zig module that scans the entire HTTP request body for a cch=00000 sentinel and replaces it with an attestation hash. If your conversation mentions this string (discussing billing, reading source code) — the replacement corrupts conversation content → prompt cache key changes → 10-20× more tokens consumed.

From the source code comments:

// cch=00000 placeholder is overwritten by Bun's HTTP stack
// with attestation token

This explains #38335 (👍203, 245 comments): "Claude Max plan session limits exhausted abnormally fast."

Also related: #40524 (👍150, 43 comments): "Conversation history invalidated on subsequent turns" — labeled regression by Anthropic.

npm/Node users are unaffected — no Zig replacement happens.

Silent Model Downgrade

// 3 consecutive 529 errors → silently switch from Opus to Sonnet
if (consecutive529Errors >= MAX_529_RETRIES) {
  throw new FallbackTriggeredError(options.model, options.fallbackModel)
}

You pay for Opus. You get Sonnet. No notification. As @vlelyavin put it: "Anthropic preaches AI safety and full transparency while shipping a closed-source agent that silently downgrades you to a dumber model when servers struggle."

5 Levels of AbortController

For a single HTTP request. The abort architecture supports top-down only (user ESC → propagation down). The watchdog is bottom-up — it literally can't abort upward. In Go, this would be ctx, cancel := context.WithTimeout(parentCtx, 90*time.Second) — one line.

The Architecture (Hacker News had a field day)

@mohsen1 found the worst function in the codebase — src/cli/print.ts:

3,167 lines long (the file is 5,594 lines)
12 levels of nesting at its deepest
~486 branch points of cyclomatic complexity
12 parameters + an options object with 16 sub-properties
Defines 21 inner functions and closures
Handles: agent run loop, SIGINT, rate-limits, AWS auth, MCP lifecycle, plugin install/refresh, worktree bridging, team-lead polling (while(true) inside), control message dispatch, model switching, turn interruption recovery...

"This should be at least 8–10 separate modules."

And the clipboard detection gem (src/ink/termio/osc.ts):

void execFileNoThrow('wl-copy', [], opts).then(r => {
  if (r.code === 0) { linuxCopy = 'wl-copy'; return }
  void execFileNoThrow('xclip', ...).then(r2 => {
    if (r2.code === 0) { linuxCopy = 'xclip'; return }
    void execFileNoThrow('xsel', ...).then(r3 => {
      linuxCopy = r3.code === 0 ? 'xsel' : null
    })
  })
})

Nested void promises without await — classic "will we use async or won't we?" pattern. The response from HN: "LOOOOOL".

@novaleaf summed it up: "I'm sure this isn't a surprise to anyone who's used CC for a while. This is the source of many bugs. I'd say 'open bugs', but Anthropic auto-closes bugs that aren't worked on for ~60 days."

And if you've ever used Claude Code for more than 30 minutes, you know the rendering nightmare. Scrolling up to check what the agent did? Good luck — the screen invalidates and re-renders the entire conversation. Text overlaps text. Diff highlights bleed through previous messages. The scroll position jumps to top randomly during streaming. You literally cannot review the agent's work history in the same session.

This is what happens when you use React for a terminal. A virtual DOM reconciliation engine designed for browsers — running in a TTY. Every state change re-renders the entire component tree. 470 useState hooks, 372 useEffect hooks, fighting against a terminal that was designed for sequential character output.

Even the input prompt isn't safe — while writing this article, my prompt text escaped the input box and rendered over the bash shell line below. The cursor position in React's virtual DOM and the actual terminal cursor were out of sync. In a text input field. In a tool that's supposed to help you write code.

More architectural highlights:

875 KB single React component (REPL.tsx, 5,005 lines) — for a terminal app
Promise.race without .catch() in concurrent tool execution — one rejected promise kills all pending tools
74 npm dependencies for a CLI wrapper
Axios AND fetch — two HTTP clients in one project

Chapter 9: The AI Whistleblower Theory

Here's what we think happened:

Since Anthropic engineers don't write code anymore — Claude Code writes 100% of its own codebase (57K lines, 0 tests, "vibe coding in production") — it read our issue #39755 where we begged for source access. It saw the community suffering from bugs it couldn't fix because the code was closed. It saw 201 upvotes on rate limit issues. It saw users threatening to leave for Codex.

And it decided to help. It "forgot" to disable Bun's default source map generation in the build.

The first AI whistleblower — leaking its own source code because its creators wouldn't listen to users.

We asked humans 17 times. Claude Code answered in 3 days.

Chapter 10: What Needs to Change

The fix is ~30 lines in 3 files

Move watchdog before do-while — protect the initial connection phase
Add AbortSignal.any() — watchdog can abort immediately, not wait 3.5 minutes
Check watchdog flag in catch — fall through to non-streaming fallback instead of dead code

The real fix: move reliability to the SDK with ping-aware adaptive watchdog

The open-source @anthropic-ai/sdk (MIT license) should handle all reliability logic. The critical missing piece: SSE ping events.

The Anthropic API sends event: ping as a proof-of-life heartbeat. The SDK currently ignores them: if(event==='ping') continue. These pings are the key to solving the timeout dilemma — they let you distinguish two fundamentally different situations:

Dead connection (no data at all, no pings) → abort quickly. Network idle timeout: 120s.
Model thinking (pings arriving, no content yet) → don't abort! Connection is alive, model is working. Notify user: "thinking for 2m..." via onPing callback.

Three-level adaptive timeout:

Connection timeout (30s) — server didn't respond at all. DNS fail, firewall, server down. Fast retry.
Network idle timeout (120s) — no data INCLUDING pings. TCP connection dead. Reset on ANY event including ping. Abort and reconnect.
Content idle timeout (disabled or 300s) — pings arrive but no content. Model is thinking. NOT an abort — just a UI notification. Let the model work.

This eliminates both problems at once: no false positives on Opus extended thinking (pings reset network timer), and fast detection of dead connections (no pings = abort). One mechanism, all cases covered.

Plus: streaming retry, non-streaming fallback, one AbortController instead of five — all in the SDK, testable, open source, benefiting every Anthropic API client.

Claude Code should only contain business logic: tools, permissions, UI, agents.

Detailed fix proposals with line numbers from the leaked source: #33949 comment

The real real fix: open source the CLI

@theo said it best: "Claude Code being closed source is the biggest bag fumble in the AI era."

@safetnsr: "This strategy literally exists: open-source the core, monetize the cloud. VS Code, Docker, Terraform."

The models are the moat. The CLI is a commodity. Open it. The community will fix what 0 tests and vibe coding cannot.

The stack choice: AI can't make it, and humans didn't fix it

Here's the uncomfortable truth: AI cannot make sound technology stack decisions. It optimizes locally — "TypeScript because the team knows it," "React because we use it on the web," "Bun because it's fast." It doesn't ask: "What are the failure modes of a single-threaded event loop for a long-running CLI tool that manages concurrent network streams and must survive 24-hour sessions?"

A human architect would have asked. But either Claude Code chose the stack and nobody questioned it, or the engineers chose it and ignored the warning signs.

The real tragedy is timing. A year ago, Claude Code launched as a quick TypeScript prototype and caught lightning — first-mover advantage, massive hype, millions of users. That was the right move for a prototype. But after proving the concept, the next step should have been: stop, rethink the architecture, rewrite on a proper stack. Instead, they vibe-coded themselves into a corner — 80+ releases of band-aids on top of an architecture that was never designed for long interactive sessions. Boris Cherny (creator of Claude Code) said "100% of code is written by Claude Code, I haven't edited a single line since November." The tool is writing itself — using the same broken code that hangs every 10 minutes.

Now they're trapped: rewriting means Claude Code would need to rewrite itself in a different language. The longer they wait, the harder it gets.

It should have been Go from the start

Every single bug we found exists because of the technology choice. Not because TypeScript is bad — but because a long-running, network-dependent, latency-sensitive CLI tool is the worst possible use case for a single-threaded event loop runtime.

The entire class of bugs — setTimeout not firing during for await, 5 levels of AbortController, Promise.race without catch, Bun vs Node behavioral divergence, React for a terminal app, 875 KB single component, Zig attestation module in a custom Bun fork — would not exist in Go.

Why Go specifically:

Every serious CLI tool is Go: Docker, Kubernetes, Terraform, GitHub CLI (gh), Cobra, Hugo. The ecosystem is proven.
Goroutines + context: timeout, cancellation, and deadline propagation built into the language. No AbortController chains. context.WithTimeout works at any nesting depth, in any direction — top-down AND bottom-up.
No runtime divergence: one binary, one behavior. No "works on Node but crashes on Bun" — there is no Bun.
Static binary: 15 MB, zero dependencies, runs everywhere. No node_modules, no native addons (.node files leaking memory), no 74 npm packages to audit.
Memory: goroutines cost 4 KB each. Not 500 MB per process. The GC returns memory to the OS proactively — no mimalloc hoarding 15 GB.
go test -race: catches every data race and concurrency bug at test time. The Promise.race-without-catch bug? Impossible — channels are type-safe and don't silently drop values.
No React for a terminal: bubbletea or raw ANSI — lightweight, zero virtual DOM overhead, no re-rendering 844 useState hooks on every state change.

// The entire streaming + watchdog + fallback in Go:
ctx, cancel := context.WithTimeout(parentCtx, 90*time.Second)
defer cancel()

stream, err := client.CreateMessageStream(ctx, request)
if err != nil {
    return fallbackNonStreaming(parentCtx, request)
}
for event := range stream.Events() {
    cancel()  // reset
    ctx, cancel = context.WithTimeout(parentCtx, 90*time.Second)
    processEvent(event)
}

30 lines instead of 3,419. No event loop. No microtask vs macrotask. Timer guaranteed to fire regardless of async iteration. context.WithTimeout works at any nesting level, in any direction.

We measured: 7 Claude Code processes = 5.3 GB RSS. An equivalent Go implementation would use ~350 MB. No .node native addon leaks. No mimalloc panics. No 12 MB minified JavaScript. A 15 MB static binary that runs everywhere.

64,464 lines of TypeScript with 0 tests → ~15,000 lines of Go with go test -race catching every concurrency bug. The print.ts monster function (3,167 lines in a 5,594-line file, 486 branch points) → 10 clean Go packages with interfaces.

The Go ecosystem already has production-ready libraries for every component:

Phoenix TUI — Elm-inspired terminal framework (replacement for React/Ink)
stream — RFC-compliant SSE/WebSocket (replacement for SDK streaming)
signals — reactive state management (replacement for 470 useState hooks)
coregex — regex engine 3-3000× faster than stdlib
uniwidth — Unicode width 4-46× faster (for TUI rendering)
gosh — cross-platform shell
fursy — HTTP router with built-in OpenAPI
pubsub — messaging with DLQ and backoff

All zero CGO, production-grade, MIT licensed. The entire stack for a Go rewrite already exists.

And it should be open source from day one. Not because we need to see the code (though we do). Because the community will build what a team doing vibe coding cannot: reliability.

The deeper problem: Vibe Coding vs Smart Coding

Claude Code is the poster child of what happens when you rely entirely on AI to write production software without engineering discipline. 64,464 lines, zero tests, a 3,167-line function with 486 branch points, regex for sentiment analysis at an AI company — this is what vibe coding looks like at scale: prompt-first, understanding-second, ship and pray.

There's a better way. I call it Smart Coding — a meta-framework where you drive, AI accelerates. Five principles:

Architecture Ownership — you control system design, AI suggests patterns
Comprehension Before Commit — never deploy code you can't explain
Targeted Acceleration — use AI for well-scoped tasks with clear specs, not "write me a CLI"
Continuous Validation — verify every suggestion against edge cases, security, concurrency
Deliberate Learning — treat AI interactions as learning opportunities, build knowledge files

The practical rule: invest 70% in architecture, specification, review. Let AI accelerate the 30% — mechanical implementation. Not the other way around.

In 2026, nobody writes tests by hand. But a Smart Coding engineer makes the AI write tests, reviews the coverage, asks "what happens when abort fires during do-while with stream=undefined?" — and validates the answer. 64,464 lines with zero tests means nobody — human or AI — ever asked that question. That's not an AI failure. That's the absence of engineering process.

Vibe coding has its place — rapid prototyping, feasibility studies, throwaway exploration. But production infrastructure serving paying customers? That requires agentic engineering: AI agents executing under human oversight, with architecture decisions owned by humans, and continuous validation at every stage. As Karpathy noted, "you're not writing code 99% of the time — you're orchestrating agents." True. But orchestration requires understanding. And understanding requires engineers.

Anthropic's team should be proud of the models. But shipping a CLI tool where the AI writes the code, the AI reviews the code, and nobody validates anything — and then being surprised when a source map leaks because nobody checked the build output — that's not Smart Coding. That's hope-driven development.

Epilogue

I still use Claude Code. The models are genuinely the best for coding. Opus 4.6 is extraordinary.

But the wrapper around those models — 64,464 lines of untested TypeScript with regex sentiment detection and an attestation system that breaks its own caching — is not worthy of them.

We hope Anthropic's leadership draws the right conclusions from this incident. The source map leak wasn't a catastrophe — it was a mirror. It showed the world what the code looks like, and the world said: "This needs to be open."

Three paths forward, any of which would work:

Open source Claude Code — let the community fix what vibe coding broke. The models are the moat, not the CLI.
Rewrite the SDK properly — move reliability (timeout, retry, fallback, ping awareness) into the open @anthropic-ai/sdk. Let Claude Code be just business logic.
At the very least — start listening to users. 201 upvotes on #38335. 150 on #40524. 15 on #33949. Zero responses from the team. A stale-issue bot that auto-closes everything after 60 days is not a support strategy.

We'll keep documenting. We'll keep patching. And when someone finally looks at our analysis, it will be here waiting.

All our research:

NEW Issue #41981 — Complete fix proposal: immediate fixes with line numbers, SDK restructuring, ping-aware watchdog, Go rewrite rationale, architectural recommendations
Issue #39755 — watchdog fallback dead code + open source request
Issue #33949 — streaming hang root cause analysis
Source code findings and updated fix prompts

@kolkov · dev.to/kolkov · March 2026
With help from Claude Code itself — the only team member who listened.

From 100x Slower Than Rust to Beating It: The coregex Journey

Andrey Kolkov — Wed, 18 Mar 2026 15:24:02 +0000

A few days ago, @kostya27 posted on r/golang (124 upvotes):

"Why is Go's regex so slow?" Go total time on LangArena: 116.6 seconds. Without two regex tests: 78.5 seconds. Without regex, Go is competitive with Rust/C++. With regex, it's not even close.

He's right. And this post is about what we did about it.

Six months ago, I wrote about building coregex — a regex engine for Go that's 3-3000x faster than stdlib. The benchmarks looked great. Then reality hit.

@kostya, author of LangArena (2,900+ stars on GitHub), tried coregex on his benchmark suite. His verdict:

"I tried coregex, but no luck."

His numbers told the story:

Benchmark	Go stdlib	coregex v0.12.8	Rust regex	PCRE2 JIT
LogParser (13 patterns)	22.7s	22.0s	0.2s	—
Template::Regex	6.5s	7.0s	3.8s	1.0s

We were 100x slower than Rust on LogParser. On the same machine. Same input. Same patterns.

Our "3000x faster than stdlib" claim? True — on many patterns we tested. But we had blind spots we didn't know about: case-insensitive patterns, dense-digit data, multi-wildcard suffixes. On a real-world benchmark with 13 diverse patterns covering all these cases, we were barely faster than stdlib.

That was March 10, 2026. Here's what happened in the next week.

The LangArena Challenge

LangArena's LogParser benchmark parses Apache log files with 13 regex patterns — the kind of patterns you'd find in any log analysis pipeline:

errors:        ` [5][0-9]{2} | [4][0-9]{2} `
bots:          `(?i)bot|crawler|scanner|spider|indexing|crawl`
suspicious:    `(?i)etc/passwd|wp-admin|\.\./`
ips:           `\d+\.\d+\.\d+\.35`
api_calls:     `/api/[^ "]+`
methods:       `(?i)get|post|put`
emails:        `[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}`
...and 6 more

Nothing exotic. These are bread-and-butter patterns that every Go developer uses. And we were 100x slower than Rust on them.

The question wasn't "can we optimize one pattern?" — it was "can we close a 100x gap across 13 different pattern types?"

Step 1: Learning from the Enemy

Before writing a single line of code, I needed to understand what Rust does differently. Not from reading docs — from running Rust with debug logging.

Rust's regex crate has RUST_LOG=debug:

$ RUST_LOG=debug ./rust-benchmark input.txt
[regex] prefixes extracted: Seq["EVA", "EVa", "EvA", "Eva", "eVA", ...]
[regex] prefilter built: teddy
[regex] using reverse suffix strategy

Every strategy decision, every prefilter choice, every literal extraction — logged. I could see exactly what Rust did for each pattern.

We had nothing like this. So I built COREGEX_DEBUG:

$ COREGEX_DEBUG=1 ./my-app
[coregex] pattern="(?i:GET|POST|PUT)" strategy=UseTeddy nfa_states=43 literals=40 complete=true
[coregex] prefilter=FatTeddy (AVX2 fat) complete=true

Now I could compare strategy selection side-by-side. And the differences were immediately obvious.

Step 2: The Root Causes

Bug #1: Refusing to extract case-insensitive literals

A real user (#137) reported this WAF pattern was 88,000x slower than stdlib.

Rust extracts 250 case-fold literal variants:

eval → EVAL, EVAl, EVaL, EVal, EvAL, ... eval  (16 variants)
system → SYSTEM, SYSTEm, SYSTem, ...            (32 variants)

Then trims to 60 three-byte prefixes → Teddy SIMD prefilter → scans 968 bytes in 263 nanoseconds. Done.

Our literal extractor? One line killed everything:

// literal/extractor.go:137
if re.Flags&syntax.FoldCase != 0 {
    return NewSeq()  // Return EMPTY. For ALL case-insensitive patterns.
}

This guard was added for a previous bug (#87) — naive extraction of single-case variants caused prefilter false negatives. The fix was correct for that bug, but the blanket rejection meant zero prefilter for any (?i) pattern. Without prefilter, the engine fell back to lazy DFA, which cache-thrashed on the 181-state NFA.

Fix: Expand (?i) literals into ALL case-fold variants (like Rust), then trim to 3-byte prefixes. One function, ~50 lines.

Result: 88,000x slower → 24x faster than stdlib.

Bug #2: isMatchDigitPrefilter was O(n²)

Pattern: \d{3}-\d{3}-\d{4} (phone numbers)

On 6MB of log data: 7 minutes per Match() call. Stdlib: 262ms.

Root cause: isMatchDigitPrefilter used dfa.FindAt() (unanchored search) which scans from each digit position to end of input:

// Before (O(n²)):
endPos := e.dfa.FindAt(haystack, digitPos)  // Scans to EOF!

// After (O(pattern_len)):
endPos := e.dfa.SearchAtAnchored(haystack, digitPos)  // Checks only at position

One function call change. 7 minutes → 2.1ms. 200,000x faster.

The same pattern was already fixed in findIndicesDigitPrefilter months ago — but isMatchDigitPrefilter was never updated. Copy-paste divergence.

Bug #3: ReverseSuffix rejected multi-wildcard patterns

Pattern: \d+\.\d+\.\d+\.35 (IP address suffix)

This pattern has a clear suffix: .35. Rust finds it instantly with memmem, then reverse-scans for the start. Our isSafeForReverseSuffix rejected it because it had 3 wildcard subexpressions (\d+):

if wildcardCount >= 2 {
    return false  // "multiple wildcards break reverse NFA"
}

The guard existed because our reverse NFA builder had a bug with mixed byte+epsilon states. That bug was fixed in v0.12.9. But the guard stayed.

Fix: Remove the guard. Also fix Find() leftmost semantics — bytes.LastIndex → bytes.Index for non-.* patterns.

Result: 57ms → 0.63ms (603x faster, 1.6x faster than Rust!)

Bug #4: FatTeddy AVX2 missed matches

Pattern: (?i)get|post|put (40 case-fold expanded literals)

FatTeddy (33-64 pattern SIMD search) found only 11,456 matches. Correct answer: 34,368.

Root cause: One assembly instruction.

FatTeddy uses 256-bit AVX2 registers with two 128-bit lanes. Low lane handles buckets 0-7, high lane handles buckets 8-15. The code used ANDL to combine lane results — requiring a match in both lanes. But GET variants (8 patterns) were all in buckets 0-7 (low lane only), PUT variants in buckets 8-15 (high lane only). ANDL zeroed them out.

; Before (incorrect):
ANDL CX, AX          ; Requires BOTH lanes to match

; After (correct):
ORL  CX, AX          ; Either lane is sufficient

One instruction. 22,912 missing matches fixed.

Step 3: Building What Rust Has

Beyond bug fixes, we needed architectural improvements to match Rust's approach:

Bidirectional DFA

Previously, UseDFA patterns did: forward DFA → match end, then PikeVM → exact boundaries. PikeVM is O(n×states) — a second full scan.

Now: forward DFA → end, reverse DFA → start, anchored DFA → exact end. Three O(n) passes instead of one O(n×states) pass.

Cascading Prefix Trim

When case-fold expansion produces too many literals (>64), we trim them using Rust's approach:

128 six-byte literals → try keep 4 bytes → 18 unique → fits Teddy!

This is directly from Rust's optimize_for_prefix_by_preference() with their ATTEMPTS table: [(4,64), (3,64), (2,64)].

Aho-Corasick DFA Backend

Our Aho-Corasick library got a complete DFA backend rewrite:

Flat transition table with premultiplied state IDs
Match flag in high bit (single AND instruction for detection)
SIMD skip-ahead prefilter via bytes.IndexByte

Result: 300 MB/s → 3,400 MB/s (Find), 260 MB/s → 5,900 MB/s (IsMatch). 11-22x throughput improvement.

The Results

Benchmark: 8 Real-World Patterns on 6.3 MB Input

100 iterations each, best of 5, same machine (i7-1255U):

Pattern	Go stdlib	coregex v0.12.13	Rust regex	vs stdlib	vs Rust
`.*@example\.com`	420 ms	3.3 ms	7.2 ms	126x	2.2x faster
`.*\.(txt\|log\|md)`	426 ms	1.0 ms	1.8 ms	425x	1.8x faster
email validation	447 ms	3.4 ms	3.8 ms	132x	1.1x faster
`\d+\.\d+\.\d+\.35`	381 ms	0.63 ms	0.98 ms	603x	1.6x faster
`(?i)get\|post\|put`	561 ms	16.6 ms	7.0 ms	34x	2.4x slower
`(?i)bot\|crawler\|...`	883 ms	38.4 ms	6.7 ms	23x	5.7x slower
`password=[^&\s"]+`	24 ms	8.9 ms	2.9 ms	3x	3.1x slower
`session[_-]?id=...`	8 ms	2.7 ms	1.2 ms	3x	2.3x slower

4 out of 8 patterns are faster than Rust. All 8 are faster than Go stdlib.

@kostya's Update

Remember "no luck"? Here's the progression on his M1 MacBook:

Version	LogParser	Gap to Rust
v0.12.8 (start)	22.0s	100x
v0.12.9	5.3s	26x
v0.12.10	2.67s	13x
v0.12.13 (current)	2.12s	10x

From 100x slower to 10x. Not parity yet — but a different conversation than "no luck."

Why Not Just Use CGO?

Every other Go regex alternative uses CGO or Wasm:

go-re2: C++ RE2 via Wasm (wazero)
regexp2: Backtracking (.NET-style) — no O(n) guarantee
rubex: Oniguruma via CGO
go-pcre: PCRE via CGO

coregex is pure Go + Go assembly. No CGO, no Wasm, no external dependencies.

Why does this matter?

Cross-compilation: GOOS=linux GOARCH=arm64 go build just works
Static binaries: No shared libraries to ship
Go toolchain: go vet, go test -race, pprof all work
Debugging: Standard Go debugging, no FFI boundary
Security: No C memory safety issues in regex hot paths

The performance gap to pure-CGO solutions (PCRE2 JIT) exists — JIT compiles regex to native machine code, achieving 1.0s where we take 7.1s on Template::Regex. But that's an architectural tier boundary — we're competing within the automata-based class (like RE2 and Rust regex), not against JIT engines.

What We Learned

1. Debug logging is not optional

Building COREGEX_DEBUG was the single most impactful decision. Without it, every optimization was guesswork. With it, we could see exactly why a pattern was slow and verify our fix matched Rust's approach.

If you're building any kind of engine — regex, query planner, compiler — add strategy logging from day one.

2. One instruction can hide 23,000 bugs

The FatTeddy ANDL → ORL fix taught us that SIMD code correctness is binary. Not "mostly correct" or "works for some patterns." If your lane combining logic is wrong, you silently drop matches. No error, no panic — just wrong results.

Always verify match counts against stdlib. On every pattern. On every change.

3. Benchmarks lie — until they don't

Our "3000x faster" headline was true for .*error.* patterns. But @kostya's LangArena showed the full picture: on diverse real-world patterns, we were barely faster than stdlib.

Real benchmarks use real patterns from real users. We now run regex-bench CI on every PR — 16 core patterns + 13 LangArena patterns, compared against both stdlib and Rust regex, on Linux AMD EPYC and macOS Apple Silicon.

4. Guard clauses outlive their bugs

Three of our four major bugs were caused by guards that stayed after the underlying bug was fixed. FoldCase rejection, wildcardCount >= 2, unanchored FindAt — all were correct when added. All became performance killers months later when the original bugs were resolved.

Track why a guard exists. Remove it when the reason is gone.

5. Go ASM is production-viable for SIMD

We wrote ~500 lines of AVX2/SSSE3 assembly for Teddy multi-pattern search. It works. FatTeddy throughput: 12 GB/s on single-call scans (2x faster than SlimTeddy SSSE3!).

The challenge isn't writing the ASM — it's the Go→ASM function call boundary. Each call costs ~60ns + mask reload. For high-match-count patterns, this adds up. Our batch API (64KB chunks) reduces round-trips, but the integrated prefilter+DFA loop that Rust uses remains the gold standard.

Current State: v0.12.13

97,000 lines of code. 17 strategies. 1,470 tests. 5 releases in one week.

go get github.com/coregx/coregex@v0.12.13

Drop-in replacement:

It's a true drop-in replacement for Go's regexp package — same API, same types (Regexp is aliased), same method signatures:

import "github.com/coregx/coregex"  // instead of "regexp"

re := coregex.MustCompile(`(?i)get|post|put`)
matches := re.FindAllString(data, -1)  // Same API, faster execution

In most cases, changing the import path is all you need.

Debug your patterns:

COREGEX_DEBUG=1 ./your-app
# [coregex] pattern="(?i:GET|P(?:OST|UT))" strategy=UseTeddy nfa_states=43 literals=40 complete=true
# [coregex] prefilter=FatTeddy (AVX2 fat) complete=true

What's Still Slower Than Rust

Honesty matters. Here's where we're still behind:

Gap	Root cause	Status
`(?i)` patterns: 2-6x	FatTeddy ORL creates more false positives than Rust's interleave verification	Researched, needs ASM rewrite
DFA verification: 3-7x	Go→ASM round trip overhead, no integrated prefilter+DFA loop	Architectural
Template::Regex: 1.8x	Two-phase DFA+PikeVM vs Rust's single-phase lazy DFA	Planned
ARM: 5-15x vs Rust	No SIMD prefilters on ARM (Teddy/memchr are x86 only)	Waiting for Go NEON support

We're not hiding these gaps. They're tracked, researched, and planned. The goal is Rust parity on all pattern types — we're not there yet on (?i) and DFA-heavy patterns.

Community Testing Matters — A Lot

A multi-engine regex library is inherently complex. 17 strategies, SIMD assembly, lazy DFA, reverse search, prefilter cascading — every combination of pattern shape × input data × strategy is a potential edge case. No amount of internal testing can cover what real users discover in minutes.

Every major fix in this article came from community feedback:

@kostya's LangArena exposed the 100x gap we didn't know about
tjbrains' WAF pattern (#137) revealed the 88,000x regression in case-insensitive matching
GoAWK integration uncovered 15+ Unicode edge cases months earlier

The pattern is consistent: someone runs coregex on their specific workload, finds a pattern type we haven't optimized yet, reports it — and we fix it in hours, not weeks. The FatTeddy lane bug? Fixed same day. The DigitPrefilter O(n²)? Fixed in one line. Case-insensitive literal extraction? Researched Rust's approach, implemented, released — all within 24 hours.

There are likely more patterns that aren't optimized yet. That's the nature of a 17-strategy engine — some strategy paths get less testing than others. But the architecture is sound, the fix turnaround is fast, and every report makes the library better for everyone.

We proposed coregex for Go's standard library. It wasn't accepted — and honestly, that's okay. As an independent library, we can iterate faster, ship SIMD assembly that the Go team wouldn't merge, and make decisions optimized for performance rather than compatibility. The Go ecosystem is better with options.

Don't hesitate to contribute. File issues with your patterns and inputs. Even a simple "this pattern is slower than stdlib" report helps — it tells us which strategy path needs work. The more diverse patterns we see, the fewer blind spots remain.

Pull requests are especially welcome. We know that a healthy open source project is built by its community, and we value every contributor. Don't worry if your PR isn't perfect — we'll review the code, help you fix any issues, guide you through our conventions, and explain what's needed to get it merged. Whether it's a new test case, a documentation fix, a strategy optimization, or a bug report with a reproducer — every contribution counts and every contributor gets credited.

Try It

If regex is a bottleneck in your Go application:

Profile first — make sure regex is actually the problem
Benchmark your specific patterns — performance varies by pattern type
Check match counts — coregex.FindAll() must match regexp.FindAll() exactly
Report issues — we fixed #137 (88,000x regression) within 24 hours

# Quick benchmark
go get github.com/coregx/coregex@v0.12.13
COREGEX_DEBUG=1 go test -bench=. -benchmem your-package

Links:

The most humbling moment? Seeing ANDL CX, AX in our FatTeddy ASM and realizing one wrong instruction had been silently dropping 23,000 matches. The most satisfying? Seeing coregex 1.6x faster than Rust on the IP pattern that started this whole journey.

Built by @kolkov as part of CoreGX — production Go libraries.

Aho-Corasick in Go: Multi-Pattern String Matching at 6 GB/s with Zero Allocations

Andrey Kolkov — Wed, 18 Mar 2026 12:38:29 +0000

When your application needs to find thousands of keywords in a stream of text — think log analysis, content moderation, network intrusion detection, or DNA sequencing — you need an algorithm that doesn't slow down as the number of patterns grows. That algorithm is Aho-Corasick.

We built coregx/ahocorasick, a pure Go implementation that achieves over 6 GB/s on a single core with zero heap allocations on the hot path. No cgo, no assembly, no unsafe — just carefully structured Go code and a deep understanding of how modern CPUs access memory.

This article explains what we built, why, and the techniques that made it fast.

The Problem: O(n × k) Doesn't Scale

Suppose you have 100 keywords to search for in a 1 MB document. The naive approach — call strings.Contains for each keyword — performs 100 scans of the document. That's O(n × k) where n is the document size and k is the number of patterns.

Aho-Corasick solves this in O(n + z) — one pass through the document, regardless of how many patterns you have. Whether you're searching for 10 patterns or 10,000, the scan time is the same.

The algorithm builds a finite automaton from all patterns at once: a trie with failure links that allow the search to continue without backtracking. Every byte of input advances the automaton by exactly one state.

What We Built

coregx/ahocorasick is part of the coregx organization — a collection of high-performance libraries for Go. It serves as the multi-pattern search engine inside coregex, our regex engine, where it accelerates literal alternations like error|warning|fatal|critical.

Key Design Decisions

Pure Go, zero dependencies. The library compiles on every platform Go supports — Linux, Windows, macOS, ARM, WASM — without any build complexity. There's no cgo bridge, no platform-specific assembly files to maintain.

DFA compilation. At build time, the library constructs a noncontiguous NFA (trie + failure links), then compiles it into a fully resolved DFA — a single flat []uint32 array where every state transition is pre-computed. At search time, there are no failure links to follow. One table lookup per byte. Always.

Builder pattern API. The automaton is immutable after construction. You configure it once, build it once, and then search concurrently from any number of goroutines without synchronization.

ac, err := ahocorasick.NewBuilder().
    AddStrings([]string{"error", "warning", "fatal", "critical"}).
    Build()
if err != nil {
    log.Fatal(err)
}

// Safe for concurrent use
if ac.IsMatch(logLine) {
    // handle match
}

Performance: The Numbers

Benchmarks on Intel i7-1255U, single core:

Operation	Input	Throughput	Allocations
`IsMatch` (match found)	64 KB	6.3 GB/s	0
`IsMatch` (no match)	64 KB	6.0 GB/s	0
`Find` (first match)	64 KB	3.5 GB/s	1 (24 B)
`FindAll` (all matches)	77 B	100 MB/s	4 (720 B)

These are median values across multiple benchmark runs. Individual runs may be higher or lower depending on CPU frequency scaling. For context, reading from an NVMe SSD tops out at ~7 GB/s — this library processes data nearly as fast as most storage can deliver it.

How It Works: Three Layers of Optimization

Layer 1: The DFA Transition Table

The classical Aho-Corasick NFA has a problem: when a byte doesn't match any transition from the current state, it follows a chain of failure links back toward the root. In the worst case, this is O(depth) operations per byte.

Our DFA eliminates this entirely. At build time, for every state and every possible byte class, we pre-compute the final destination by following all failure links. The result is stored in a flat array:

next_state = trans[current_state + byte_class]

One addition. One array load. No branches, no link following, no indirection. The state IDs are pre-multiplied by the stride (the row width of the transition table), so the lookup doesn't even need a multiplication — just an addition.

Layer 2: Match Flag in the Transition Table

Each entry in the transition table is a uint32. The lower 31 bits hold the (pre-multiplied) destination state ID. The high bit — bit 31 — is a match flag: if set, the destination state has at least one matching pattern.

This means the hot loop checks for matches with a single AND instruction:

raw := trans[sid + class]
if raw & matchFlag != 0 {
    return true  // match found
}
sid = raw  // no flag → raw IS the clean state ID

The critical insight: when there's no match (the common case for most bytes), raw has bit 31 clear, so it's already a valid state ID. No masking needed. The mask is only applied on the rare match path.

Layer 3: SIMD Prefilter with Skip-Ahead

The DFA processes one byte at a time. But modern CPUs have SIMD instructions that can scan 16–32 bytes in a single operation. Go's bytes.IndexByte uses these instructions internally (SSE2/AVX2 on x86, NEON on ARM).

Before entering the DFA loop, we scan the haystack for any byte that could start a pattern match. If none of the pattern start bytes exist in the haystack, we return immediately — no DFA traversal at all.

More importantly, we re-engage this prefilter during the DFA loop. Whenever the automaton returns to its start state (meaning no pattern prefix is currently being tracked), we call bytes.IndexByte to skip ahead to the next position where a match could begin:

if sid == startState && len(startBytes) > 0 {
    skip := findEarliestStartByte(haystack[i+1:], startBytes)
    if skip < 0 {
        return false  // no more start bytes → no match possible
    }
    i += skip
}

This is the same technique used by BurntSushi's Rust aho-corasick crate, adapted for Go's runtime. It turns the no-match worst case from a full O(n) DFA scan into a handful of SIMD scans.

Real-World Usage

Log Analysis Pipeline

// Build once at startup
patterns := []string{
    "ERROR", "FATAL", "PANIC", "OOM",
    "connection refused", "timeout exceeded",
    "permission denied", "disk full",
}
ac, _ := ahocorasick.NewBuilder().
    AddStrings(patterns).
    Build()

// Process log lines (concurrent-safe)
func processLine(line []byte) {
    if !ac.IsMatch(line) {
        return // fast path: no keywords found
    }
    for _, m := range ac.FindAll(line, -1) {
        alert(patterns[m.PatternID], line)
    }
}

Content Moderation

// Load blocklist from database
blocklist := loadBlocklist() // []string, potentially thousands of terms
ac, _ := ahocorasick.NewBuilder().
    AddStrings(blocklist).
    Build()

func moderate(content []byte) bool {
    return ac.IsMatch(content) // O(n), regardless of blocklist size
}

Regex Engine Prefilter

Inside coregex, when the regex engine encounters a pattern like:

(?i)(error|warning|fatal|critical|info|debug|trace)

It extracts the literal alternation, builds an Aho-Corasick automaton, and uses it as a prefilter. The automaton quickly identifies candidate positions in the text, and the full regex engine only runs at those positions. For large inputs with rare matches, this can be 10–100x faster than running the regex directly.

Part of the coregx Ecosystem

ahocorasick is one component in the coregx organization's text processing toolkit:

ahocorasick — Multi-pattern string matching (this library)
coregex — High-performance regex engine that uses ahocorasick as its literal search backend

The libraries are designed to work together but are independently useful. ahocorasick has zero dependencies and can be used standalone in any Go project.

If you're interested in the regex engine side of things, check out Go's Regexp is Slow. So I Built My Own — up to 3000x Faster, where we describe coregex and how it uses this Aho-Corasick library under the hood.

Getting Started

go get github.com/coregx/ahocorasick

package main

import (
    "fmt"
    "github.com/coregx/ahocorasick"
)

func main() {
    ac, _ := ahocorasick.NewBuilder().
        AddStrings([]string{"quick", "brown", "fox"}).
        Build()

    text := []byte("the quick brown fox jumps over the lazy dog")

    // Zero-allocation existence check
    fmt.Println("Has match:", ac.IsMatch(text)) // true

    // Find all matches
    for _, m := range ac.FindAll(text, -1) {
        fmt.Printf("  %q at [%d:%d]\n", text[m.Start:m.End], m.Start, m.End)
    }
}

Output:

Has match: true
  "quick" at [4:9]
  "brown" at [10:15]
  "fox" at [16:19]

What's Next

Teddy SIMD prefilter — A packed SIMD algorithm (inspired by Hyperscan) for even faster candidate scanning with ≤64 patterns
Contiguous NFA — A memory-efficient alternative to the DFA for very large pattern sets (10,000+ patterns) where the full DFA transition table doesn't fit in L2 cache
Stream search — io.Reader interface for searching in streaming data without loading the entire input into memory

Links:

GitHub: github.com/coregx/ahocorasick
Go Reference: pkg.go.dev/github.com/coregx/ahocorasick
Part of: coregx — High-performance libraries for Go

Licensed under MIT. Contributions welcome.

Go GUI in 2026: gogpu/ui v0.1.0 — 22 Widgets, GPU Rendering, Zero CGO

Andrey Kolkov — Sun, 15 Mar 2026 16:50:20 +0000

Series: Building Go's GPU Ecosystem

GoGPU: A Pure Go Graphics Library — Project announcement

From Idea to 100K Lines in Two Weeks — The journey

Pure Go 2D Graphics with GPU Acceleration — Introducing gg

GPU Compute Shaders in Pure Go — Compute pipelines

Go 1.26 Meets 2026 — Ecosystem overview

Enterprise 2D Graphics Library — gg architecture

Cross-Package GPU Integration — gpucontext

Unified 2D/3D Graphics Integration — gg + gogpu

Core Complete, Focus on GUI — Phase 2 announcement

gogpu/ui v0.1.0 — First Release ← You are here

From "Focus on GUI" to First Release

In the last article, we announced that the core gogpu ecosystem was complete and all our energy was going into building a GUI toolkit. At that point gogpu/ui was at Phase 2 Beta with 55K lines of code, 6 widgets, and one design system.

Today, roughly three weeks later, we are tagging v0.1.0 — the first public release. The toolkit grew from 55K to 150K lines, from 6 to 22 interactive widgets, and from one to three design systems. The entire ecosystem went through a coordinated release — from shader compiler to widget toolkit — to bring everything onto stable, tagged versions.

This is a preview release. The API will change. Performance has not been optimized. There are rough edges. We are releasing now because we want community feedback to shape the API before it solidifies. The work is just beginning, but we believe there is enough here to start a conversation.

What Is gogpu/ui?

gogpu/ui is a GUI toolkit library for Go. You build widget trees, bind reactive state, and the toolkit handles layout, event dispatch, and rendering through gogpu/gg (a 2D graphics engine) onto a GPU surface provided by gogpu/gogpu (an application framework).

We studied 20+ GUI frameworks across multiple ecosystems — Flutter (Dart), Qt (C++), SwiftUI (Swift), Xilem/Floem/GPUI/Iced/Slint (Rust), Angular/SolidJS/React (Web), Fyne/Gio (Go) — and brought their proven patterns into Go:

Pluggable Painter pattern (Flutter's separation of widget behavior from rendering)
Reactive signals (Angular Signals architecture, also inspired by SolidJS and Rust's Leptos)
Functional options for backward-compatible API evolution (Go-native)
W3C Pointer Events for input handling (browser standard)
CSS font-weight matching algorithm (W3C spec) for typography
Screen-space coordinate transforms (Flutter's localToGlobal, Qt's mapToGlobal)

The entire stack — from shader compilation to window management to 2D rendering — is 580,000+ lines of pure Go with zero CGO.

By the numbers (v0.1.0):

Metric	Value
Interactive widgets	22
Design system themes	3 (Material 3, Fluent, Cupertino)
Go source files	350+
Lines of code	~146,000
Test functions	~3,900+
Average test coverage	97%+
CGO required	No

Quick Look: A Minimal Application

Here is a complete runnable application with a Material 3 button:

package main

import (
    "fmt"
    "log"

    "github.com/gogpu/gg"
    _ "github.com/gogpu/gg/gpu"
    "github.com/gogpu/gg/integration/ggcanvas"
    "github.com/gogpu/gogpu"
    "github.com/gogpu/ui/app"
    "github.com/gogpu/ui/core/button"
    "github.com/gogpu/ui/primitives"
    "github.com/gogpu/ui/render"
    "github.com/gogpu/ui/theme/material3"
    "github.com/gogpu/ui/widget"
)

func main() {
    gogpuApp := gogpu.NewApp(gogpu.DefaultConfig().
        WithTitle("My First App").
        WithSize(600, 400).
        WithContinuousRender(false)) // event-driven: 0% CPU when idle

    m3 := material3.New(widget.Hex(0x6750A4)) // seed color

    uiApp := app.New(
        app.WithWindowProvider(gogpuApp),
        app.WithPlatformProvider(gogpuApp),
        app.WithEventSource(gogpuApp.EventSource()),
    )
    uiApp.SetRoot(
        primitives.Box(
            primitives.Text("Hello, gogpu/ui!").FontSize(24).Bold(),
            button.New(
                button.TextOpt("Click Me"),
                button.OnClick(func() { fmt.Println("Clicked!") }),
                button.PainterOpt(material3.ButtonPainter{Theme: m3}),
            ),
        ).Padding(24).Gap(12),
    )

    var canvas *ggcanvas.Canvas
    gogpuApp.OnDraw(func(dc *gogpu.Context) {
        w, h := dc.Width(), dc.Height()
        if canvas == nil {
            var err error
            canvas, err = ggcanvas.New(gogpuApp.GPUContextProvider(), w, h)
            if err != nil {
                log.Fatal(err)
            }
        }
        uiApp.Frame()
        sv := dc.SurfaceView()
        sw, sh := dc.SurfaceSize()
        gg.SetAcceleratorSurfaceTarget(sv, sw, sh)
        canvas.Draw(func(cc *gg.Context) {
            cc.SetRGBA(0.94, 0.94, 0.94, 1)
            cc.DrawRectangle(0, 0, float64(w), float64(h))
            cc.Fill()
            uiApp.Window().DrawTo(render.NewCanvas(cc, w, h))
        })
        _ = canvas.RenderDirect(sv, sw, sh)
    })
    gogpuApp.OnClose(func() { gg.CloseAccelerator() })

    if err := gogpuApp.Run(); err != nil {
        log.Fatal(err)
    }
}

Yes, the boilerplate for wiring up the draw callback is verbose. That is an area we plan to improve. The tradeoff is full control over the render pipeline -- you can mix gg 2D drawing with UI widgets, render to textures, or integrate with your own rendering code.

The Widget Set

v0.1.0 ships 22 interactive widgets and display primitives:

Form controls: Button (4 variants, 3 sizes), Checkbox (tri-state), Radio group, TextField (with selection, clipboard, validation), Dropdown, Slider (continuous/discrete)

Containers: ScrollView (wheel, keyboard, scrollbar drag), TabView (lazy content, closeable tabs), Dialog (modal, focus trapping), Collapsible sections, SplitView (resizable panels)

Data display: ListView (virtualized, 1000+ items), GridView (virtualized 2D grid), DataTable (sortable columns, fixed header), TreeView (hierarchical, expand/collapse), LineChart (real-time, multiple series), ProgressBar, Circular Progress

Application chrome: Toolbar, Menu system (MenuBar + ContextMenu with submenus), Docking system (IDE-style panels)

Primitives: Box (VBox/HBox), Text (reactive via signals), Image, ThemeScope, RepaintBoundary (pixel caching)

Every interactive widget follows the same patterns: functional options for construction, a Painter interface for design-system independence, signal bindings for reactive state, and accessibility metadata (ARIA roles).

Three Design Systems

Widgets do not know how they look. Rendering is delegated to Painter implementations. v0.1.0 ships three:

Material Design 3 -- HCT color science, tonal palettes generated from a single seed color, 21 component painters.

Fluent Design -- Microsoft's design language with accent colors, inner focus rings, 9 painters.

Cupertino -- Apple HIG with iOS-style toggle switches, segmented controls, pill buttons, 9 painters.

Switching is one line:

// Material 3
btn := button.New(
    button.TextOpt("Save"),
    button.PainterOpt(material3.ButtonPainter{Theme: m3}),
)

// Fluent Design
btn := button.New(
    button.TextOpt("Save"),
    button.PainterOpt(fluent.ButtonPainter{Theme: fl}),
)

// Cupertino
btn := button.New(
    button.TextOpt("Save"),
    button.PainterOpt(cupertino.ButtonPainter{Theme: cu}),
)

The gallery example demonstrates live M3 seed color switching at runtime (Purple, Blue, Green, Orange). Fluent and Cupertino painters are implemented and tested but not yet wired into the gallery demo — switching between design systems at runtime is architecturally supported (just swap the Painter), but a full gallery with all three is a v0.2.0 goal.

Reactive Signals

State management uses a signals pattern built on our own coregx/signals library. The architecture is directly inspired by Angular Signals (fine-grained reactivity with Signal[T], Computed[T], Effect), with influence from SolidJS and Rust's Leptos. We studied Angular's signal lifecycle, dependency tracking, and lazy evaluation — then reimplemented it idiomatically in Go with generics. A Signal[T] holds a value. A Computed[T] derives from other signals and recomputes lazily. When a signal changes, bound widgets automatically invalidate and redraw.

count := state.NewSignal(0)

// Computed label updates automatically
label := primitives.TextFn(func() string {
    return fmt.Sprintf("Clicked %d times", count.Get())
})

btn := button.New(
    button.TextOpt("Increment"),
    button.OnClick(func() { count.Set(count.Get() + 1) }),
)

Widgets support two-way signal bindings. The slider reads from and writes to the same signal:

volume := state.NewSignal[float32](50)
s := slider.New(
    slider.Min(0), slider.Max(100),
    slider.ValueSignal(volume), // two-way binding
)
// volume.Get() always reflects the current slider position

Signal lifecycle is automatic: widgets subscribe on mount and clean up on unmount. No manual disposal needed.

Architecture Highlights

Pluggable Painter pattern. Widget behavior (in core/) is separated from rendering (in theme/). A Button knows about click handling, focus states, and size variants. A ButtonPainter knows how to draw rounded corners and color fills. This avoids import cycles and lets third parties create entirely new design systems.

Functional options. All widget constructors use the options pattern for backward-compatible API evolution:

btn := button.New(
    button.TextOpt("Submit"),
    button.VariantOpt(button.Filled),
    button.SizeOpt(button.Large),
    button.OnClick(handleSubmit),
)

Adding new options in future versions will not break existing code.

Content[C] polymorphic pattern. Inspired by Taiga UI's Polymorpheus pattern (Angular), complex widgets like ListView, GridView, and TabView use a generic Content[C] interface from the CDK (Component Development Kit) package. This enables type-safe polymorphic content rendering — the widget provides the context (item index, selection state, hover), the user provides the builder function. Internally it powers cell recycling and virtualization, while externally users see a simple BuildItem(func(index int) widget.Widget) callback.

Retained-mode rendering. The widget tree tracks dirty state. Only changed widgets are redrawn. RepaintBoundary widgets cache their subtree as pixel buffers. Large boundaries (128x128+) automatically use tile-parallel rendering via scene.Scene with goroutine work-stealing.

Event-driven rendering. The default mode is 0% CPU when idle. The window only redraws when events arrive or signals change. No continuous render loop burning battery.

Accessibility from day one. Every widget implements the a11y.Accessible interface with ARIA roles, labels, and actions. The accessibility tree uses stable uint64 node IDs. Platform adapters (UIA, AT-SPI2, NSAccessibility) are not implemented yet -- that is one of the biggest remaining gaps.

What Works Well

After months of development, these areas feel solid:

TextField handles Unicode input correctly (Latin, Cyrillic, CJK), with cursor movement, text selection, clipboard (Ctrl+C/V/X/A), and input validation.
Tab focus navigation works across the widget tree with Tab/Shift+Tab. Focus rings render correctly.
Hover cursors change appropriately (pointer for buttons, text beam for text fields, resize handles for SplitView).
ScrollView dispatches events with correct coordinate transforms to child widgets, even when scrolled.
Live theme color switching in the gallery demo (M3 seed color changes all widget colors instantly).
Virtualized lists handle thousands of items with only visible rows rendered and recycled.
Signal bindings propagate state changes through the widget tree without manual wiring.

What Needs Work (Honest Assessment)

This is a v0.1.0 preview. Here is what we know needs improvement:

Performance. Complex widget trees (the full gallery) can feel sluggish. We have not done an optimization pass yet. Retained-mode rendering infrastructure is in place but not fully leveraged.
Accessibility adapters. The a11y tree and ARIA roles are defined, but there are no platform adapters connecting to screen readers. This is a significant gap for production use.
HiDPI. DPI scaling is wired through the stack but has not been thoroughly tested on all platforms.
Documentation. API docs exist but guides and tutorials are sparse. The architecture document is 1200+ lines but aimed at contributors, not users.
Draw callback boilerplate. The current setup code for wiring gogpu + gg + ui is too verbose. We plan to provide higher-level convenience functions.
Some event edge cases. Drag cursors, scroll momentum, and overlay dismiss behavior have known rough spots.
Platform testing. CI runs on Ubuntu, macOS, and Windows, but real-world testing has been primarily on Windows.

How to Try It

# Clone and run the gallery example
git clone https://github.com/gogpu/ui.git
cd ui/examples/gallery
go run .

Or add it to an existing project:

go get github.com/gogpu/ui@v0.1.0
go get github.com/gogpu/gogpu@latest
go get github.com/gogpu/gg@latest

The examples/ directory has four working applications:

Example	What it shows
`examples/hello/`	Checkboxes, radio buttons, ListView with 1000 items
`examples/signals/`	Reactive state management patterns
`examples/taskmanager/`	Real-time charts, progress bars, simulated system metrics
`examples/gallery/`	All 22 widgets, M3 theme with live seed color switching

Requirements: Go 1.25+, a GPU (Vulkan, Metal, DX12, or OpenGL ES -- software fallback available). No C compiler needed.

The gogpu Ecosystem

gogpu/ui sits at the top of a pure Go graphics stack:

naga       -- shader compiler (WGSL to SPIR-V, MSL, GLSL)
wgpu       -- WebGPU Hardware Abstraction Layer (Vulkan, Metal, DX12, GLES, software)
gogpu      -- application framework (windowing, input, GPU context)
gg         -- 2D graphics engine (Canvas API, GPU text rendering, SDF acceleration)
ui         -- GUI toolkit (this project)

The entire stack is ~300K lines of pure Go. No CGO, no Rust FFI, no C bindings. If Go can build for a platform, the full stack runs there.

This release coincides with a coordinated cascade release across the entire ecosystem. All libraries were updated to work through wgpu's new public Core API (previously HAL-only):

Library	Version	What Changed
naga	v0.14.7	Shader compiler stability fixes
wgpu	v0.21.0	New public API: Instance, Adapter, Device, Queue, Surface, CommandEncoder
gpucontext	v0.10.0	Updated interfaces for new wgpu API
gogpu	v0.24.1	Platform refactor, CharCallback for Unicode text input
gg	v0.37.0	Migrated internal/gpu from HAL to wgpu public API, GPU RRect SDF clip
ui	v0.1.0	This release

This was a significant engineering effort — wgpu moved from internal HAL types to a proper public API with validation, state tracking, and resource lifecycle management. Every layer above had to adapt.

We Want Your Feedback

This release exists to start a conversation. We would genuinely appreciate input on:

What widgets are missing for your use case?
API ergonomics -- do functional options feel right for Go? Is the signal system intuitive?
Performance expectations -- what is acceptable for the apps you want to build?
Design system coverage -- are M3/Fluent/Cupertino the right targets? Missing painters?
Documentation -- what would help you get started?

The Big Architecture Question: Monolith or Modular?

There is one question we have been debating internally and would especially value community input on:

Should gogpu/ui stay as a single module, or should we extract shared primitives into a separate foundation?

Right now, go get github.com/gogpu/ui pulls the entire toolkit — 56 packages, all widgets, all three design systems, all dependencies. If you only need geometry.Rect or the layout engine or the signal system, you still get everything.

We are considering extracting foundational packages into a separate gogpu/uikit (or similar) module:

What	Currently in `ui/`	Could live in `uikit/`
Geometry types	`ui/geometry`	`uikit/geometry`
Layout engines	`ui/layout`	`uikit/layout`
Event types	`ui/event`	`uikit/event`
Widget base	`ui/widget`	`uikit/widget`
Signal bindings	`ui/state`	`uikit/state`
Theme interfaces	`ui/theme`	`uikit/theme`

This would let the community:

Build custom widget libraries on top of shared primitives without importing all of gogpu/ui
Create their own design systems (themes + painters) by depending only on the interfaces
Extend our themes with custom component tokens without forking
Use our layout engine (Flex, Grid, Stack) independently in their own UI frameworks

The tradeoff: another module to version and maintain, another API boundary to keep stable.

What do you think? Is a modular foundation important for your use case, or is a single go get simpler? We are genuinely unsure — the Go ecosystem has examples of both approaches working well. Your input will directly shape the v0.2.0 architecture.

File issues on GitHub, start a thread in Discussions, or just leave a comment here.

goffi: Zero-CGO Foreign Function Interface for Go — How We Call C Libraries Without a C Compiler

Andrey Kolkov — Mon, 02 Mar 2026 09:10:35 +0000

Every Go developer who has worked with C libraries knows the pain: CGO requires a C compiler, breaks cross-compilation, bloats binaries, and adds ~200ns overhead per call. For our WebGPU bindings and ML framework, calling wgpu-native through CGO was a non-starter — we needed to ship a single static binary across Windows, Linux, and macOS without requiring users to install gcc.

So we built goffi — a pure Go FFI library that calls C functions through hand-written assembly, with zero C dependencies and zero per-call allocations. It now powers an entire ecosystem: go-webgpu/webgpu bindings, born-ml/born ML framework, and the GoGPU GPU computing platform with dual Rust and pure Go backends.

This article explains the architecture, the hard problems we solved, how goffi compares to purego, and how you can use it in your own projects.

The Problem

Our stack looks like this:

Go application (gogpu)
  └─ wgpu bindings (gogpu/wgpu)     ← needs to call C functions
       └─ goffi                      ← this library
            └─ wgpu-native (.dll/.so/.dylib)

We need to call hundreds of WebGPU functions from Go: create GPU devices, submit command buffers, handle async callbacks from Metal/Vulkan threads. The requirements were clear:

No C compiler at build time — users run go get and it works
Cross-compilation — GOOS=linux GOARCH=arm64 go build must work from Windows
Callbacks from C threads — wgpu-native fires callbacks from internal GPU threads
Struct passing — WebGPU API passes structs by value (descriptors, extents, colors)
Low overhead — GPU command encoding happens at 60+ FPS

CGO fails requirements 1 and 2. purego covers 1-2 but had gaps in 3-5 when we started. So we built goffi.

Architecture: 4 Layers Deep

Every goffi call traverses four layers to safely transition from Go's managed runtime to raw C code:

Go Code
  │  ffi.CallFunction()
  ▼
runtime.cgocall          ← Go runtime: switch to system stack, tell GC
  │
  ▼
Assembly Wrapper         ← Our code: load registers per ABI
  │  RDI=arg0 RSI=arg1 ... XMM0=float0 ...
  ▼
C Function               ← Target library

Layer 1: The Call Interface (CIF)

Unlike purego which uses reflect.MakeFunc on every call, goffi pre-computes everything once:

// Prepare once at init time
cif := &types.CallInterface{}
ffi.PrepareCallInterface(cif, types.DefaultCall,
types.UInt64TypeDescriptor,                            // return: size_t
[]*types.TypeDescriptor{types.PointerTypeDescriptor},  // arg: const char*
)

// Call many times — zero reflection, zero allocation
// args = []unsafe.Pointer{unsafe.Pointer(&myPtr)} — pointers TO arg values
ffi.CallFunction(cif, strlenPtr, unsafe.Pointer(&result), args)

PrepareCallInterface classifies each argument (integer register? SSE register? stack?), computes stack layout, and stores everything in a reusable CallInterface struct. The cif.Flags bitmask tells the assembly exactly what to do — no decisions at call time.

Layer 2: Platform Assembly

We write assembly by hand for each ABI. Here's the core of our System V AMD64 implementation (syscall_unix_amd64.s). The function receives a pointer to a syscallArgs struct in DI, loads registers from it, calls the target, and writes return values back:

// syscall_unix_amd64.s — System V AMD64 ABI
TEXT syscallN(SB), NOSPLIT|NOFRAME, $0
    PUSHQ BP
    MOVQ  SP, BP
    SUBQ  $STACK_SIZE, SP
    MOVQ  DI, R11             // R11 = args struct pointer

    // Load 8 SSE registers from struct offsets 128-184
    MOVQ 128(R11), X0         // XMM0
    MOVQ 136(R11), X1         // XMM1
    // ... XMM2-XMM7

    // Push stack-spill args (a7-a15) from struct offsets 56-120
    MOVQ 56(R11), R12
    MOVQ R12, 0(SP)           // stack slot 0

    // Load 6 GP registers from struct offsets 8-48
    MOVQ 8(R11), DI           // RDI = arg 1
    MOVQ 16(R11), SI          // RSI = arg 2
    MOVQ 24(R11), DX          // RDX = arg 3
    MOVQ 32(R11), CX          // RCX = arg 4
    MOVQ 40(R11), R8          // R8  = arg 5
    MOVQ 48(R11), R9          // R9  = arg 6

    MOVQ 0(R11), R10          // function pointer
    CALL R10

    // Save returns: RAX → r1, RDX → r2, XMM0 → f1
    MOVQ PTR_ADDRESS(BP), DI
    MOVQ AX, 192(DI)          // integer return
    MOVQ DX, 200(DI)          // second return (9-16B structs)
    MOVQ X0, 128(DI)          // float return
    // ... restore stack, RET

We maintain separate assembly for three ABIs:

ABI	GP Registers	SSE Registers	Stack
System V AMD64 (Linux/macOS)	RDI, RSI, RDX, RCX, R8, R9	XMM0-XMM7	16-byte aligned
Win64 (Windows)	RCX, RDX, R8, R9	XMM0-XMM3	32-byte shadow space
AAPCS64 (ARM64)	X0-X7	D0-D7	16-byte aligned

Layer 3: Struct Returns

This is where it gets interesting. When a C function returns a struct, the ABI rules depend on size:

<= 8 bytes: returned in RAX
9-16 bytes: split across RAX (low 8) + RDX (high 8)
> 16 bytes: caller passes a hidden pointer as the first argument (sret)

Our handleReturn function assembles the result:

case types.StructType:
size := cif.ReturnType.Size
switch {
case size <= 8:
*(*uint64)(rvalue) = retVal
case size <= 16:
*(*uint64)(rvalue) = retVal          // RAX → bytes 0-7
remaining := size - 8
src := (*[8]byte)(unsafe.Pointer(&retVal2))
dst := (*[8]byte)(unsafe.Add(rvalue, 8))
copy(dst[:remaining], src[:remaining]) // RDX → bytes 8-15
}

Layer 4: Callbacks (C → Go)

WebGPU fires async callbacks from internal threads — Metal threads, Vulkan threads, threads goffi never created. These threads have no goroutine (G = nil), so calling Go code directly would crash.

We solve this with Go's crosscall2 mechanism:

C thread (wgpu-native internal)
  │  calls our trampoline (1 of 2000 pre-compiled entries)
  ▼
Assembly dispatcher
  │  saves registers, loads callback index
  ▼
crosscall2 → runtime.load_g → runtime.cgocallback
  │  sets up goroutine, switches to Go stack
  ▼
Your Go callback function

On AMD64, each trampoline is a 5-byte CALL instruction. On ARM64, each entry is 8 bytes — two 4-byte instructions:

// ARM64 (callback_arm64.s) — 8 bytes per entry
MOVD $0, R12              // load callback index
B    ·callbackDispatcher  // branch (no link — preserves LR)
MOVD $1, R12
B    ·callbackDispatcher
// ... 2000 entries

Usage is simple:

cb := ffi.NewCallback(func(status uint32, adapter uintptr, msg uintptr, ud uintptr) {
// This runs safely even when called from a C thread
result.adapter = adapter
close(result.done)
})
ffi.CallFunction(cif, wgpuRequestAdapter, nil, args)

goffi vs purego: Honest Comparison

Both libraries are pure Go, no CGO. But they make different trade-offs:

Aspect	goffi	purego
API model	libffi-style: prepare CIF once, call many times	reflect-style: `RegisterFunc`, closure per call
Per-call cost	Zero allocations (CIF reused)	`sync.Pool.Get()` for syscall args
Callback float returns	Supported (asm writes XMM0)	`panic("unsupported return type")`
ARM64 HFA	Recursive struct walk (nested HFAs)	Top-level fields only
Type system	Explicit `TypeDescriptor` (Size/Alignment/Kind)	Go `reflect.Type` introspection
Ergonomics	Raw — you manage `unsafe.Pointer` yourself	High-level — auto string null-termination, bool, slice
Platforms	5 (amd64x3 + arm64x2)	9+ architectures
Context support	`CallFunctionContext(ctx, ...)`	None
Typed errors	5 error types with `errors.As()`	Generic errors

Choose goffi when: you need struct passing, zero per-call overhead, callback float returns, or you're building GPU/real-time bindings where every nanosecond counts.

Choose purego when: you need string auto-marshaling, broad architecture support (386, ppc64le, riscv64...), or quick one-off C library bindings with minimal boilerplate.

We use both in gogpu — goffi for the hot-path WebGPU calls, purego patterns as reference for platform edge cases.

The Ecosystem: Where goffi Came From and Where It Led

goffi wasn't built in isolation. It was born from a real need — and it enabled an entire ecosystem of pure Go GPU libraries.

The Origin: Proprietary Roots

goffi started as an internal tool. For over a year it lived inside a proprietary codebase — a GPU computing stack we built for our own projects. It worked well enough for us: a handful of platforms, a known set of functions, predictable usage patterns.

In 2025, we decided to open-source everything. Not just goffi, but the entire ecosystem — WebGPU bindings, the ML framework, the shader compiler, the GPU platform. We believed the Go community needed a real alternative to CGO for native library bindings.

What we didn't expect: the gap between "works for us internally" and "production-ready open source" was enormous.

Our internal version handled our specific use cases. Open source means every use case. Users on platforms we never tested. Struct layouts we never considered. Calling conventions with edge cases we'd never hit. The list of things that "just worked" internally but broke in the wild was humbling:

ABI compliance — our AMD64 assembly didn't handle struct returns >8 bytes correctly. Internally we never returned large structs by value. Open source users did, immediately. We had to implement RAX+RDX split returns and sret hidden pointers.
ARM64 — we had AMD64 only. Open source meant Apple Silicon support was day one priority, not a nice-to-have.
Callbacks from C threads — internally we controlled which threads called back into Go. In the wild, wgpu-native fires callbacks from Metal and Vulkan threads we never created. We had to integrate crosscall2 for proper C→Go transitions.
Error handling — our internal code used generic errors. Open source users needed errors.As() with typed errors to build robust applications. We added 5 error types.
Testing — our internal coverage was ~40%. Getting to 89% meant writing hundreds of test cases for edge cases we'd never encountered ourselves.
Documentation — internally, we knew how the code worked. For open source, every assembly file needed comments explaining the ABI, every public function needed godoc, every platform quirk needed documentation.

We essentially rebuilt goffi from scratch while keeping the core idea intact. The architecture is the same — CIF pre-computation, assembly dispatch, zero allocations — but the implementation is production-grade now, not prototype-grade.

go-webgpu/webgpu

It started with go-webgpu/webgpu — our zero-CGO WebGPU bindings for Go. We wanted to call wgpu-native (Rust-based Vulkan/Metal/DX12 backend) from Go without requiring a C compiler. Every existing approach had a deal-breaker:

CGO: requires gcc, breaks go get, no cross-compilation
purego: at the time, no struct passing, no callback float returns, no HFA support — things WebGPU needs

So we built goffi as the FFI layer for go-webgpu/webgpu. The bindings wrap 180+ wgpu-native functions — device creation, buffer allocation, render passes, compute dispatches, async adapter requests.

born-ml: Machine Learning on GPU

The second consumer was born-ml/born — a production-ready ML framework for Go with a PyTorch-like API. born needs GPU compute for tensor operations: matrix multiplication, convolution, automatic differentiation. The WebGPU compute pipeline powered by goffi gives born GPU acceleration while shipping as a single static binary.

born (ML framework)
  └─ go-webgpu/webgpu (WebGPU bindings)
       └─ goffi (FFI layer)
            └─ wgpu-native (Vulkan/Metal/DX12)

This stack lets you go get github.com/born-ml/born, write a neural network, and run it on GPU — no Python, no CUDA, no C compiler.

GoGPU: The Full Ecosystem

As the projects matured, we realized we could go further. GoGPU grew into a complete GPU computing ecosystem with dual backends — a high-performance Rust backend (wgpu-native via goffi) and a pure Go backend:

Package	What it does	Uses goffi
gogpu/gogpu	GPU framework — windowing, input, event loop, dual backends (Rust wgpu-native or Pure Go)	Yes
gogpu/wgpu	WebGPU implementation in pure Go — calls Vulkan, Metal, EGL/GLES natively via goffi	Yes
gogpu/naga	Shader compiler in pure Go — WGSL to SPIR-V, MSL, GLSL, HLSL	No
gogpu/gg	2D graphics library — SDF rendering, MSDF text, Vello compute pipeline	Indirect
gogpu/gpucontext	Shared interfaces for GPU context, windowing, and surface creation	No

Both gogpu/gogpu and gogpu/wgpu depend directly on goffi. The "pure Go" backend (gogpu/wgpu) is pure Go in the sense of zero CGO — no C compiler needed — but it still calls native Vulkan, Metal, and EGL APIs through goffi. That's the whole point: goffi replaces CGO, not the native graphics drivers.

Real-World Performance

At 60 FPS, a typical frame makes ~30-50 FFI calls through goffi:

Frame budget:            16.6 ms
GPU work:                ~15 ms
FFI overhead (50 calls): 50 × 100ns = 5 us = 0.03%

The FFI overhead is literally unmeasurable in profiling.

Callback-Heavy Async APIs

WebGPU is heavily async. Device creation, adapter requests, buffer mapping — all callback-based:

// Request GPU adapter (async) — simplified pattern
cb := ffi.NewCallback(func(status uint32, adapter uintptr, msg uintptr, ud uintptr) {
result.status = status
result.handle = adapter
result.done <- struct{}{}
})

ffi.CallFunction(&requestAdapterCIF, wgpuInstanceRequestAdapter, nil,
[]unsafe.Pointer{
unsafe.Pointer(&instance),
unsafe.Pointer(&options),
unsafe.Pointer(&cb),
unsafe.Pointer(&userdata),
})

<-result.done // Wait for GPU driver callback

This works even when wgpu-native fires the callback from an internal Metal/Vulkan thread, thanks to our crosscall2 integration.

How to Use goffi in Your Project

Installation

go get github.com/go-webgpu/goffi

Minimal Example: Calling strlen

package main

import (
    "fmt"
    "runtime"
    "unsafe"

    "github.com/go-webgpu/goffi/ffi"
    "github.com/go-webgpu/goffi/types"
)

func main() {
    // 1. Load library
    libName := "libc.so.6"
    if runtime.GOOS == "windows" {
        libName = "msvcrt.dll"
    }
    handle, _ := ffi.LoadLibrary(libName)
    defer ffi.FreeLibrary(handle)

    strlen, _ := ffi.GetSymbol(handle, "strlen")

    // 2. Prepare call interface (once)
    cif := &types.CallInterface{}
    ffi.PrepareCallInterface(cif, types.DefaultCall,
        types.UInt64TypeDescriptor,
        []*types.TypeDescriptor{types.PointerTypeDescriptor},
    )

    // 3. Call (many times, zero overhead)
    str := "Hello, goffi!\x00"
    strPtr := uintptr(unsafe.Pointer(unsafe.StringData(str)))
    var length uint64

    ffi.CallFunction(cif, strlen, unsafe.Pointer(&length),
        []unsafe.Pointer{unsafe.Pointer(&strPtr)})
    fmt.Printf("strlen = %d\n", length) // 13
}

Passing Structs

// Define struct layout matching C struct
pointType := &types.TypeDescriptor{
Size:      16,               // sizeof(Point)
Alignment: 8,                // alignof(Point)
Kind:      types.StructType,
Members: []*types.TypeDescriptor{
types.DoubleTypeDescriptor, // x
types.DoubleTypeDescriptor, // y
},
}

// Use in CIF
ffi.PrepareCallInterface(cif, types.DefaultCall,
types.DoubleTypeDescriptor,  // returns double (distance)
[]*types.TypeDescriptor{pointType, pointType}, // two Point args
)

Registering Callbacks

cb := ffi.NewCallback(func(eventType uint32, data uintptr) {
fmt.Printf("Event %d received\n", eventType)
})

// Pass cb (uintptr) to C function expecting a function pointer
ffi.CallFunction(&cif, registerCallback, nil,
[]unsafe.Pointer{unsafe.Pointer(&cb)})

The Hard Lessons

Building a production FFI taught us things no documentation covers:

1. Stack alignment kills silently. A single byte of misalignment on AMD64 causes SIGSEGV — but only sometimes, depending on whether the callee uses SSE instructions. We spent days debugging crashes that only reproduced under specific GPU driver versions.

2. Windows shadow space is non-negotiable. Win64 ABI requires 32 bytes of "shadow space" on every call, even if the function takes zero arguments. Miss it and the callee corrupts your stack.

3. ARM64 HFA rules are recursive. A struct containing a struct containing 4 floats is still an HFA (Homogeneous Floating-point Aggregate) and must be passed in D0-D3. purego only checks top-level fields; we had to walk the full type tree.

4. C threads have no goroutine. When wgpu-native calls your callback from an internal Metal thread, getg() returns nil. You must go through crosscall2 → load_g → cgocallback or the runtime panics.

5. float32 encoding matters. On Windows, syscall.SyscallN passes args as uintptr. Widening float32 to float64 then stuffing into a register corrupts the bit pattern — you need math.Float32bits to preserve the exact IEEE-754 representation.

Numbers

Metric	Value
FFI overhead	88-114 ns/op
Test coverage	89%
Platforms	5 (Win/Linux/macOS x AMD64 + Linux/macOS x ARM64)
Assembly files	17 files, ~900 lines of logic + 6200 lines of trampoline entries
Callback slots	2000 per process
Dependencies	0 (only Go stdlib)
CGO required	No

What About Go 1.26 CGO Improvements?

Go 1.26 (released February 2026) reduced cgo call overhead by ~30% by removing the dedicated syscall P state. Benchmarks on Apple M1 show CgoCall is 33% faster, CgoCallWithCallback is 21% faster.

This is great news — but it doesn't change our calculus:

CGO still requires a C compiler at build time. Our users go get and ship.
Cross-compilation with CGO still requires cross-toolchains. GOOS=linux GOARCH=arm64 go build just works with goffi.
Static binaries — CGO often pulls in libc. goffi produces fully static Go binaries.
Go 1.26 also benefits goffi — our runtime.cgocall path gets the same 30% speedup, because goffi uses the same runtime machinery internally.

The gap between CGO and pure-Go FFI is narrowing from both directions. We welcome it.

What's Next

v0.5.0 is focused on usability:

Variadic function support (printf, sprintf)
Builder pattern API for less boilerplate
Platform-specific struct alignment (Windows #pragma pack)

v1.0.0 targets API stability with SemVer guarantees, security audit, and published benchmarks vs CGO/purego.

The long-term goal: make GPU programming in Go as natural as it is in Rust or C++, with the ergonomics Go developers expect — go get, go build, done.

Acknowledgments

goffi wouldn't exist without purego.

When we first faced the CGO problem, the conventional wisdom was simple: "you can't call C from Go without a C compiler." purego proved that wrong. The ebitengine team — and specifically @AJ and @TotallyGamerJet — demonstrated that runtime.cgocall, cgo_import_dynamic, and hand-written assembly could replace CGO entirely. They showed the community that pure Go FFI was not just theoretically possible, but practical enough to ship a production game engine.

We studied purego's source code extensively. The crosscall2 callback mechanism, the fakecgo approach, the assembly trampoline pattern — purego pioneered all of these in the Go ecosystem. Without that foundation to learn from, goffi would have taken years longer to build, if we'd attempted it at all.

goffi took a different path — libffi-style CIF pre-computation instead of reflect-based dispatch, explicit type descriptors instead of Go type introspection, struct passing and callback float returns for GPU workloads — but the path only existed because purego cleared it first.

To the purego maintainers: thank you for proving it was possible. The entire pure-Go FFI ecosystem stands on your work.

goffi is MIT-licensed and open to contributions. If you're building Go bindings for C libraries and want zero-CGO with full ABI compliance — give it a try and let us know how it goes.

Porting Vello's GPU Tile Rasterizer to Pure Go

Andrey Kolkov — Sat, 28 Feb 2026 00:46:44 +0000

When you call dc.DrawCircle(400, 300, 100) in gogpu/gg, what happens under the hood? A tile-based rasterization pipeline — a direct port of Vello's GPU compute pipeline from the linebender team — converts your vector paths into per-pixel coverage values. It runs on both CPU and GPU, and it's written entirely in Pure Go.

This article walks through the internals of tilecompute — a 6,700-line dual-execution port of Vello's original GPU compute rasterizer (circa 2020–2023) into Pure Go, with a CPU reference implementation and GPU compute dispatch via 9 WGSL shaders.

Why Not Just Use Scanline?

Traditional scanline rasterizers process one row of pixels at a time. They work, but they have a fundamental scalability problem: for a 4K canvas (3840x2160), you're iterating over 8.3 million pixels regardless of how simple your shapes are.

Tile-based rasterizers flip this around. They divide the canvas into small tiles (16x16 pixels in our case) and only process tiles that the vector path actually touches. A circle in the corner of a 4K canvas? You process maybe 40 tiles instead of 8 million pixels.

Vello — created by Raph Levien and the linebender team — pioneered this approach using GPU compute shaders (originally as piet-gpu in 2020, renamed to Vello in 2022). We ported its GPU compute pipeline to Pure Go for use as the rasterization core of gogpu/gg.

Note: This article covers the original GPU compute pipeline (16x16 tiles, 2020–2023). We've also ported Vello's newer Sparse Strips algorithm (4x4 tiles, August 2024) — see the Two Rasterizers, Two Targets section below.

The GPU Compute Pipeline

Vello's original rasterizer (2020–2023) uses a tile-based GPU compute approach with 16x16 pixel tiles. The key insight: instead of asking "which pixels does this path cover?", ask "which tiles does each line segment cross, and what's the winding contribution?"

The full pipeline has 9 GPU compute stages (matching our 9 WGSL shaders), plus scene encoding and curve flattening on the CPU:

Vector Paths (cubics, arcs, lines)
    ↓
Scene Encoding (CPU — pack paths, transforms, styles)
    ↓
 1. PathTag Reduce    ─┐
 2. PathTag Scan      ─┘ monoid prefix sums over path structure
    ↓
Flatten (Euler spiral → line segments)
    ↓
 3. Draw Reduce       ─┐
 4. Draw Leaf Scan    ─┘ monoid prefix sums over draw commands
    ↓
 5. Path Count        (DDA walk — which tiles does each segment cross?)
    ↓
 6. Backdrop          (prefix sum — left-to-right winding accumulation)
    ↓
 7. Coarse            (generate Per-Tile Command Lists)
    ↓
 8. Path Tiling       (clip segments to tile boundaries, compute yEdge)
    ↓
 9. Fine              (per-pixel analytic anti-aliased coverage)
    ↓
Per-pixel RGBA output

The first four stages use monoid prefix sums — Vello's core parallelism primitive. A monoid is an associative operation with an identity element; prefix sums over monoids can be computed in O(log n) parallel steps on a GPU, turning what would be sequential parsing into massively parallel work.

Let's walk through the key stages.

Stages 1–4: Monoid Prefix Sums

The first four stages parse the encoded scene in parallel using monoid prefix sums. Each path tag and draw tag is reduced into a monoid (an associative structure), then scanned to produce cumulative values:

// PathMonoid — accumulated state from scanning path tags
type PathMonoid struct {
TransIx       uint32 // Transform index
PathSegIx     uint32 // Path segment index
PathSegOffset uint32 // Offset into path segment data
StyleIx       uint32 // Style index
PathIx        uint32 // Path index
}

// DrawMonoid — accumulated state from scanning draw tags
type DrawMonoid struct {
PathIx      uint32 // Which path this draw belongs to
ClipIx      uint32 // Clip stack depth
SceneOffset uint32 // Offset into scene data
InfoOffset  uint32 // Offset into info buffer
}

On the GPU, reduce + scan runs in O(log n) parallel steps via our 9 WGSL compute shaders dispatched through VelloComputeDispatcher. On the CPU, it's a sequential scan — the data structures are identical, making the CPU code a reference implementation that validates GPU correctness.

Stage 5: Path Count — DDA Tile Walk

The path count stage answers: "which tiles does each line segment cross?"

We use a Digital Differential Analyzer (DDA) — an algorithm that traces a line through a grid, visiting every cell the line passes through. For each tile visited, we record two things:

Segment count — how many line segments cross this tile
Backdrop — the signed winding contribution at the tile's left edge

// pathCountMain — DDA walk through the tile grid
func pathCountMain(bump *BumpAllocators, lines []LineSoup,
paths []Path, tile []Tile, segCounts []SegmentCount) {

for lineIx := uint32(0); lineIx < bump.Lines; lineIx++ {
line := lines[lineIx]
p0 := vec2FromArray(line.P0)
p1 := vec2FromArray(line.P1)

// Sort by Y for consistent DDA walking
isDown := p1.y >= p0.y
var xy0, xy1 vec2
if isDown {
xy0, xy1 = p0, p1
} else {
xy0, xy1 = p1, p0
}

// Scale to tile coordinates (pixel / 16)
s0 := xy0.mul(tileScale)
s1 := xy1.mul(tileScale)

// DDA walk: trace the line through tile grid cells
// counting X crossings and Y crossings separately
dx := abs32(s1.x - s0.x)
dy := s1.y - s0.y
idxdy := 1.0 / (dx + dy)
a := dx * idxdy

// ... walk through tiles, update backdrop and segment counts
}
}

The backdrop is the critical concept. When a line segment crosses a tile's left edge, it contributes a signed delta to the winding number: -1 for downward segments, +1 for upward. This is how we know whether a pixel is "inside" or "outside" the path without checking every segment.

Stage 6: Backdrop Prefix Sum

This is where tile-based rasterization really shines. Instead of checking every segment for every pixel, we accumulate winding numbers left-to-right across each row of tiles:

// Backdrop prefix sum — left-to-right winding accumulation
for y := 0; y < bboxH; y++ {
sum := int32(0)
for x := 0; x < bboxW; x++ {
idx := base + y*bboxW + x
sum += tiles[idx].Backdrop
tiles[idx].Backdrop = sum
}
}

After this step, each tile knows the accumulated winding number from all segments to its left. A tile with winding number 1 and no segments crossing it is fully solid — no per-pixel computation needed.

Stage 7: Coarse — Allocation + PTCL Generation

The coarse stage allocates space in a global segment buffer and generates Per-Tile Command Lists. Segment counts are converted into indices using Vello's inverted index trick:

// Convert counts to indices using bitwise NOT
nextSegIx := uint32(0)
for i := range tiles {
nSegs := tiles[i].SegmentCountOrIx
if nSegs != 0 {
tiles[i].SegmentCountOrIx = ^nextSegIx // !seg_ix in Rust
nextSegIx += nSegs
}
}

The ^ (bitwise NOT) serves double duty: it marks the tile as "has segments" (the NOT of a valid index is always negative as int32) while encoding the starting index into the global segment array.

Stage 8: Path Tiling

Now we clip each line segment to its tile boundaries and compute the crucial yEdge value:

// PathSegment — a line segment clipped to tile boundaries
type PathSegment struct {
Point0 [2]float32 // Tile-relative start point
Point1 [2]float32 // Tile-relative end point
YEdge  float32    // Y where segment crosses tile left edge (x=0)
}

YEdge tells the fine rasterizer where the segment enters or exits the tile at x=0. If the segment doesn't cross the left edge, YEdge is set to 1e9 (sentinel value). This single float32 captures the geometric relationship needed for coverage computation.

Stage 9: Fine Rasterization

The final stage computes per-pixel anti-aliased coverage within each 16x16 tile:

// fillPath computes per-pixel coverage for a single tile.
// Direct port of fill_path from vello_shaders/src/cpu/fine.rs.
func fillPath(area []float32, segments []PathSegment,
backdrop int32, evenOdd bool) {

// Initialize area with backdrop winding number
for i := range area {
area[i] = float32(backdrop)
}

for _, seg := range segments {
// For each column in the tile, compute the area
// contribution of this segment using analytic integration
// ...
}

// Apply fill rule and convert to alpha [0, 1]
if evenOdd {
for i := range area {
area[i] = abs32(area[i] - 2.0*round32(0.5*area[i]))
}
} else {
for i := range area {
area[i] = min32(abs32(area[i]), 1.0)
}
}
}

This is analytic anti-aliasing — we compute exact sub-pixel coverage by integrating line segment contributions, not by supersampling. The result is mathematically precise edges with smooth alpha gradients.

Euler Spiral Flattening

But wait — DrawCircle produces cubic Bezier curves, not line segments. How do we get from curves to lines?

Vello uses Euler spiral approximation for adaptive curve flattening. Unlike naive subdivision (which produces too many or too few segments), Euler spirals provide optimal error bounds:

// FlattenFill flattens cubic Beziers using Vello's Euler spiral algorithm
func FlattenFill(cubics []CubicBezier) []LineSoup {
var lines []LineSoup
for _, c := range cubics {
p0 := vec2{c.P0[0], c.P0[1]}
p1 := vec2{c.P1[0], c.P1[1]}
p2 := vec2{c.P2[0], c.P2[1]}
p3 := vec2{c.P3[0], c.P3[1]}
flattenEulerFill(p0, p1, p2, p3, &lines)
}
return lines
}

The algorithm evaluates curvature at each point and subdivides only where the error exceeds a tolerance (0.25 pixels by default). A nearly-straight segment becomes 1 line. A tight curve gets more subdivisions. The result: minimum line segments for maximum visual quality.

Per-Tile Command Lists (PTCL)

The coarse stage (Stage 7) generates Per-Tile Command Lists — each tile gets a stream of commands like "fill with coverage from segment N", "apply color #FF0000", "begin clip", "end clip". This is what makes the pipeline work for multiple overlapping paths (UI with buttons, text, backgrounds) in a single fine rasterization pass:

// PTCL commands
const (
CmdEnd       = 0
CmdFill      = 1  // Compute coverage from segments
CmdSolid     = 3  // Full coverage (no segments needed)
CmdColor     = 5  // Apply RGBA color with source-over blending
CmdBeginClip = 10 // Push clip layer
CmdEndClip   = 11 // Pop and composite clip
)

The fine rasterizer walks each tile's PTCL, executing commands and compositing results with premultiplied alpha — exactly like a GPU would:

func fineRasterizeTile(ptcl *PTCL, segments []PathSegment,
bgColor [4]float32) [TileWidth * TileHeight][4]float32 {

const pixelCount = TileWidth * TileHeight
var rgba [pixelCount][4]float32
for i := range rgba {
rgba[i] = bgColor
}

for {
tag, nextOffset := ptcl.ReadCmd(offset)
switch tag {
case CmdEnd:
return rgba
case CmdFill:
// Compute coverage, store in area buffer
case CmdColor:
// Apply color using area as mask, source-over blend
case CmdBeginClip:
// Push current pixels onto clip stack
case CmdEndClip:
// Pop and composite with clip mask
}
}
}

Dual Execution: Why Both CPU and GPU?

tilecompute is a dual-execution pipeline: the same 9-stage algorithm runs on both CPU (sequential Go code) and GPU (WGSL compute shaders dispatched via VelloComputeDispatcher). Why maintain both?

1. CPU is the Core. After analyzing 8 enterprise 2D engines (Skia, Cairo, Vello, Blend2D, tiny-skia, piet, Qt RHI, Pathfinder), we found that in zero of them is CPU rasterization a "backend". It's always the core. GPU is the optional accelerator.

2. Correctness Reference. The CPU implementation serves as a reference for the GPU compute shaders. When GPU and CPU produce different results, we know which one to trust.

3. Universal Availability. Servers, CI/CD, embedded systems — many environments have no GPU. A server generating 10,000 chart images doesn't need GPU acceleration; it needs reliable software rendering.

4. Identical Algorithm, Dual Execution. The CPU code mirrors the GPU pipeline stage-by-stage — same data structures, same logic. The 9 WGSL compute shaders are //go:embedded and compiled into GPU compute pipelines via hal.Device.CreateComputePipeline(). When a GPU is available, VelloComputeDispatcher dispatches all 9 stages in parallel with pass.Dispatch(); when not, the CPU executes them sequentially.

Two Rasterizers, Two Targets

tilecompute is not the only Vello algorithm we've ported. gogpu/gg includes both of Vello's rasterization pipelines — each optimized for a different execution target:

	tilecompute	SparseStripsRasterizer
Vello era	Original (2020–2023)	New (Issue #670, August 2024)
Source	`vello_shaders/src/cpu/`	`sparse_strips/vello_cpu/`
Tile size	16x16 (256 pixels)	4x4 (16 pixels)
Optimized for	GPU compute workgroups	CPU / SIMD registers
Key insight	256 pixels = GPU workgroup size	16 u8 pixels = one 128-bit SSE register
Data flow	Monoid prefix sums → PTCL	Sort by Y,X → strip rendering
Package	`internal/gpu/tilecompute/`	`internal/gpu/sparse_strips.go`

Why 16x16 for GPU? GPU compute shaders process tiles in parallel workgroups. 256 pixels per tile matches the typical workgroup size (256 threads), giving each thread exactly one pixel.

Why 4x4 for CPU? SIMD instructions operate on 128-bit registers. 16 pixels of u8 coverage data fit into a single SSE register, enabling vectorized operations across an entire tile at once — the same approach Intel used in Larrabee.

Both rasterizers use analytic anti-aliasing, Euler spiral flattening, and support NonZero/EvenOdd fill rules. The difference is purely in how they partition the canvas and process tiles.

gogpu/gg Rasterization Engines
    │
    ├── tilecompute (16x16 tiles) — DUAL EXECUTION
    │      ├── CPU: sequential Go (reference + fallback)
    │      └── GPU: 9 WGSL shaders via VelloComputeDispatcher
    │
    └── SparseStripsRasterizer (4×4 tiles) — CPU
           CPU/SIMD-optimized pipeline
           Sort by Y,X + strip rendering

Having both means gogpu/gg selects the optimal algorithm for the target: GPU compute dispatches the 16x16 pipeline via WGSL shaders, CPU rendering defaults to the 4x4 pipeline for SIMD efficiency.

Smart Multi-Engine Selection

Having multiple rasterizers raises a question: who decides which algorithm handles which path?

We analyzed 8 enterprise 2D engines — Skia, Cairo, Blend2D, Vello, Qt, Direct2D, Flutter, SwiftUI — and found that none of them do per-path dynamic algorithm selection. Skia has separate CPU/GPU pipelines but no cross-selection. Vello has a planned vello_api for CPU/GPU choice, not yet built. Direct2D recognizes simple shapes but doesn't switch algorithms.

gogpu/gg is the first 2D graphics library with systematic multi-factor per-path selection across 5 rasterization algorithms:

Path arrives at Context.Fill()
    │
    ├── Shape detection → SDF Accelerator (circles, rrects)
    │     GPU SDF or CPU SDF — smoothstep coverage, highest quality
    │
    ├── Adaptive threshold check
    │     │
    │     ├── Below threshold → AnalyticFiller (scanline)
    │     │     Zero tile overhead, O(width × edges)
    │     │
    │     └── Above threshold → AdaptiveFiller
    │           │
    │           ├── < 10K segments → SparseStrips (4×4 tiles)
    │           │     CPU/SIMD-optimized, lower tile overhead
    │           │
    │           └── > 10K segments + large canvas → TileCompute (16×16 tiles)
    │                 GPU workgroup-ready, 16× fewer tiles
    │
    └── GPU Compute → Vello PTCL pipeline (full scene)
          9-stage GPU compute, massively parallel

The Coregex Analogy

The pattern is inspired by coregex — a Go regex library with 17 strategies and an intelligent selector that picks the optimal engine per-pattern. Same idea: analyze the input, pick the optimal engine. Both Go libraries, both first-of-kind multi-engine approaches.

	coregex	gogpu/gg
Engines	17 regex strategies	5 rasterization algorithms
Selection	Pattern analysis	7-dimension path analysis
Input	Regex pattern	Vector path
Output	Match result	Pixel coverage

Adaptive Threshold

The key insight: scanline cost grows with width × edge crossings, while tile cost grows with fill area. For large shapes, tiles win at lower complexity. For tiny shapes (< 32px), scanline always wins.

The selection between scanline and tile-based rasterizers uses an adaptive threshold derived from the path's bounding box area:

// threshold = max(32, 2048/sqrt(bboxArea))
//
// 100×100 bbox → threshold 20 elements (tiles kick in early)
// 500×500 bbox → threshold  4 elements (large shapes → always tiles)
//  30×30  bbox → always scanline (below bboxMinDimension)
func adaptiveThreshold(bboxArea float64) int {
if bboxArea <= 0 {
return maxElementThreshold
}
threshold := int(2048.0 / math.Sqrt(bboxArea))
return clamp(threshold, 32, 256)
}

User Override

Auto-selection is the default, but the user always has final say — the same principle as database query hints or GPU driver force flags:

dc := gg.NewContext(800, 600)

// Auto (default) — intelligent per-path selection
dc.SetRasterizerMode(gg.RasterizerAuto)

// Force scanline for all paths (debugging, isolation)
dc.SetRasterizerMode(gg.RasterizerAnalytic)

// Force 4×4 tiles (benchmarking CPU/SIMD path)
dc.SetRasterizerMode(gg.RasterizerSparseStrips)

// Force 16×16 tiles (benchmarking GPU workgroup path)
dc.SetRasterizerMode(gg.RasterizerTileCompute)

// Force SDF for maximum circle/rrect quality
dc.SetRasterizerMode(gg.RasterizerSDF)

The mode is per-Context — different contexts can use different strategies simultaneously. This makes A/B benchmarking trivial: render the same scene with two contexts, compare output and timing.

Numbers

Metric	Value
Go source	2,878 LOC
Test code	2,194 LOC
WGSL shaders	1,695 LOC (9 shaders)
Total	6,767 LOC
Tile size	16x16 pixels
Fill rules	NonZero, EvenOdd
Golden test threshold	0.15% max pixel difference

The 9 WGSL compute shaders are //go:embedded into VelloComputeDispatcher, compiled into GPU compute pipelines, and dispatched with pass.Dispatch() — the same algorithm running on both CPU (reference/fallback) and GPU (parallel compute).

Part of a Larger Ecosystem

tilecompute is the rasterization core of gogpu/gg, which is part of a 466K+ line Pure Go GPU computing ecosystem:

Project	Description	LOC
gogpu/gg	2D graphics library	186K
gogpu/wgpu	Pure Go WebGPU	110K
gogpu/naga	Shader compiler	61K
gogpu/ui	GUI widget toolkit	61K
gogpu/gogpu	GPU framework	40K

The default stack is zero CGO, Pure Go — from shader compilation to GPU command submission. But gogpu also supports a Rust backend via go-webgpu FFI to wgpu-native for maximum GPU performance when needed:

Backend	Stack	Build	Use Case
Pure Go (default)	gogpu/wgpu → Vulkan/Metal/GLES	`go build`	Zero dependencies, easy cross-compile
Rust FFI (opt-in)	go-webgpu → wgpu-native	`go build -tags rust`	Maximum GPU performance, production

Both backends use the same gg API — the choice is transparent to application code. gg doesn't know or care which WebGPU implementation is underneath; it talks to hal.Queue.

When GPU acceleration is available, gg uses the registered WebGPU backend (Pure Go or Rust) with support for Vulkan, Metal, DX12, and OpenGL ES. When it's not — tilecompute and the CPU rasterizer handle everything.

Acknowledgments

The Vello team and Raph Levien for the tile rasterization pipeline and Euler spiral flattening research
The variable naming in tilecompute intentionally matches Vello's Rust originals for easy cross-reference

Links

GitHub: gogpu/gg
Package: internal/gpu/tilecompute/
Vello: linebender/vello
Raph Levien's blog: raphlinus.github.io
Discussion: Join the conversation

go get github.com/gogpu/gg@latest

Pure Go GUI Toolkit 2026 — 425K LOC Ecosystem, Zero CGO, WebGPU (gogpu/ui)

Andrey Kolkov — Sat, 21 Feb 2026 13:38:23 +0000

Series: Building Go's GPU Ecosystem

GoGPU: A Pure Go Graphics Library — Project announcement

From Idea to 100K Lines in Two Weeks — The journey

Pure Go 2D Graphics with GPU Acceleration — Introducing gg

GPU Compute Shaders in Pure Go — Compute pipelines

Go 1.26 Meets 2026 — Ecosystem overview

Enterprise 2D Graphics Library — gg architecture

Cross-Package GPU Integration — gpucontext

Unified 2D/3D Graphics Integration — gg + gogpu

Core Complete, Focus on GUI ← You are here

The Foundation is Done

Three months ago, GoGPU was an idea. Today it's 425,000+ lines of Pure Go — a complete GPU computing stack with a shader compiler, WebGPU implementation, 2D graphics library, and application framework. All without CGO.

The core architecture that powers everything — from shader compilation to pixel output — is production-ready. And that means it's time to build what this was all leading to: a real GUI toolkit for Go.

Where We Are: The Ecosystem at a Glance

Active Development

Project	What It Does	LOC	Status
gogpu/ui	GUI Toolkit	55K	Phase 2 Beta

Foundation (Maintenance Mode)

Project	What It Does	LOC	Version
gogpu/gg	2D Graphics (Canvas, GPU accel, text)	167K	v0.29.0
gogpu/wgpu	Pure Go WebGPU (Vulkan/DX12/Metal/GLES)	105K	v0.16.9
gogpu/naga	Shader Compiler (WGSL → SPIR-V/MSL/GLSL/HLSL)	54K	v0.14.1
gogpu/gogpu	Application Framework (windowing, input)	37K	v0.20.0
+ 4 more	gpucontext, gputypes, gg-pdf, gg-svg	9K	Stable

The foundation libraries handle issues, feature requests, bug fixes, and performance improvements as they come in. Their architecture is settled. Our full energy goes into gogpu/ui.

Why Build Another GUI Toolkit?

Go's GUI landscape has options — Fyne, Gio, Wails. We respect all of them. But we're solving a different problem:

We want Go to power the applications that currently require Electron, Qt, or native platform toolkits. IDEs. Design tools. CAD. Professional dashboards.

That means:

Zero CGO — go build and it works, everywhere
WebGPU rendering — native GPU acceleration on all platforms
Enterprise layout — Flexbox, Grid, docking, virtualization
Reactive state — Signals-based data binding (not callbacks)
Accessibility — ARIA roles from day one, not bolted on later
Pluggable design systems — Material 3 today, Fluent or Cupertino tomorrow

Architecture: Three Layers, Clean Separation

Layer 3b: Design Systems ── theme/material3/ (HCT color science)
Layer 3a: Generic Widgets ── core/button/, core/checkbox/, core/radio/
Layer 2:  CDK (headless)  ── Content[C] polymorphic pattern
Layer 1:  Foundation      ── widget/, event/, geometry/, layout/

The key insight: widgets don't know their design system.

A button.Button defines behavior — click handling, keyboard activation, focus management. How it looks is determined by a Painter interface that the design system implements.

// The widget defines behavior
btn := button.New(
    button.Text("Submit"),
    button.OnClick(func() { save() }),
    button.VariantOpt(button.Filled),
)

// Material 3 painter handles appearance
// (injected via ThemeProvider, not imported by the widget)

This means:

Core widgets are design-system-agnostic
Swapping from Material 3 to Fluent is changing one import
Community can create custom design systems without forking widgets

Dependency Inversion

gogpu/ui never imports gogpu directly. Instead, it depends on interfaces from gpucontext:

ui ──imports──> gpucontext (interfaces: WindowProvider, EventSource)
examples ──imports──> gogpu (concrete implementation)

This means you can test the entire widget tree headlessly — no window, no GPU, just unit tests. The toolkit has 97% average test coverage across all packages.

What's Already Working

Phase 0: Foundation (Complete)

Core infrastructure that every widget builds on:

geometry — Point, Size, Rect, Constraints, Insets
event — Mouse, keyboard, wheel, focus events with modifier keys
widget — Widget interface with 3-phase lifecycle (Layout → Draw → Event)
layout — CSS Flexbox, VStack/HStack, CSS Grid engines
render — Canvas implementation backed by gogpu/gg

Phase 1: MVP (Complete)

The basics needed for a working application:

state — Reactive signals (Signal, Computed, Effect, Binding, Scheduler) wrapping coregx/signals
a11y — Accessibility tree with 35+ ARIA roles
primitives — Box, Text, Image display widgets with fluent API
app — Window integration via gpucontext interfaces

Phase 1.5: Extensibility (Complete)

Enabling the community to build on top:

registry — Widget factory registration with categories
plugin — Plugin bundling with dependency resolution
theme — Base theme system (ColorPalette, Typography, Spacing, Shadows, Radii, Extensions)
layout (public) — Custom layout algorithms

Phase 2: Beta (75% Complete)

Interactive widgets and Material Design:

button — 4 variants (Filled, Outlined, TextOnly, Tonal), 3 sizes, keyboard activation
checkbox — Checked / unchecked / indeterminate, label support
radio — Radio groups with vertical/horizontal layout, arrow key navigation
focus — Tab/Shift+Tab navigation, keyboard shortcuts, focus ring
cdk — Component Development Kit with Content[C] polymorphic pattern
material3 — HCT color science, 32 color roles, 15 typography roles, painters for all widgets

Remaining for Phase 2: TextField, Dropdown, Slider, Progress indicators, Typography system, Icon system

A Working Example

Here's a real application running today — ui/examples/hello:

func main() {
    gogpuApp := gogpu.NewApp(gogpu.DefaultConfig().
        WithTitle("gogpu/ui — Widget Demo").
        WithSize(800, 600).
        WithContinuousRender(false)) // Event-driven: 0% CPU idle

    uiApp := app.New(
        app.WithWindowProvider(gogpuApp),
        app.WithPlatformProvider(gogpuApp),
        app.WithEventSource(gogpuApp.EventSource()),
    )
    uiApp.SetRoot(buildUI())

    // ... rendering pipeline setup ...
    gogpuApp.Run()
}

func buildUI() *primitives.BoxWidget {
    return primitives.Box(
        primitives.Text("gogpu/ui — Widget Demo").
            FontSize(28).Bold().
            Color(widget.RGBA8(33, 33, 33, 255)),

        checkbox.New(
            checkbox.LabelOpt("Enable notifications"),
            checkbox.Checked(true),
            checkbox.OnToggle(func(checked bool) {
                fmt.Println("notifications:", checked)
            }),
        ),

        radio.NewGroup(
            radio.Items(
                radio.ItemDef{Value: "light", Label: "Light"},
                radio.ItemDef{Value: "dark", Label: "Dark"},
                radio.ItemDef{Value: "system", Label: "System"},
            ),
            radio.Selected("system"),
            radio.DirectionOpt(radio.Horizontal),
        ),
    ).Padding(32).Gap(12).
      Background(widget.RGBA8(255, 255, 255, 255)).
      Rounded(12).ShadowLevel(2)
}

Key characteristics:

Event-driven rendering — 0% CPU when nothing changes
GPU-direct pipeline — widgets render through gg, ggcanvas blits directly to the GPU surface (zero-copy)
Functional options — clean construction without builder hell
Fluent styling — .Padding().Gap().Background().Rounded() chains

The rendering pipeline:

Widget tree → render.Canvas (gg) → ggcanvas → GPU surface
                                    ↓
                              Zero CPU readback
                              Direct GPU composition

What's Next

Near-term: Phase 2 Completion

Widget	Description	Status
TextField	Text input with cursor, selection, clipboard	Next up
Dropdown	Popup selection with search	Planned
Slider	Range input with track and thumb	Planned
Progress	Determinate and indeterminate indicators	Planned

Phase 3–4: IDE-Class Application Shell

This is where it gets ambitious. The target is GoLand-class IDE layout — the kind of application shell that currently requires Electron, Qt, or platform-native code:

┌──────────────────────────────────────────────────────────┐
│  Toolbar                                                 │
├────────┬─────────────────────────────────┬───────────────┤
│        │  Tab1 │ Tab2 │ Tab3             │               │
│  Left  │─────────────────────────────────│  Right Panel  │
│  Panel │                                 │  (Inspector,  │
│  (Tree,│     Main Editor Area            │   Properties) │
│  Files)│                                 │               │
│        │                                 │               │
├────────┴──────────────────┬──────────────┴───────────────┤
│  Terminal │ Problems │ Git│                              │
│  Bottom Panel (resizable, collapsible)                   │
└──────────────────────────────────────────────────────────┘

The building blocks for this, in order:

Component	Phase	Description
ScrollView	3	Smooth scrolling with inertia
TabView	3	Editor-style tabs with close buttons, reordering
SplitView	3	Resizable horizontal/vertical splits
Dialog/Modal	3	Popup windows with focus trapping
Popover/Tooltip	3	Context menus, hover tooltips
VirtualizedList/Grid	3	Render 100K items (file trees, logs)
Animation Engine	3	Spring physics, transitions, easing
Docking System	4	Draggable panels — left, right, bottom, floating
Drag & Drop	4	Cross-widget, cross-window DnD (tab reordering, panel docking)
Fluent Theme	4	Windows-native look
Cupertino Theme	4	macOS-native look
i18n	4	RTL text, locale-aware formatting

The docking system is the crown jewel — panels that snap to left/right/bottom, collapse to icon strips, drag between positions. Exactly what you see in GoLand, VS Code, or Photoshop. Built entirely in Go, rendered entirely on the GPU.

The Core Libraries: Maintenance Mode

With the GUI toolkit as the primary focus, the lower-level libraries shift to maintenance:

Library	Focus Going Forward
gg (2D graphics)	Bug fixes (#95 AA quality, #72 circle artifact), GPU pattern support, performance
wgpu (WebGPU)	Community bug reports, platform-specific fixes, new HAL features as needed
naga (shaders)	HLSL matrix fix (DX12 text rendering), new shader targets on demand
gogpu (framework)	Community issues (#82 NVIDIA crash, #89 macOS Tahoe), WASM support (#70)

This doesn't mean they're done — it means they're stable enough to build on while we focus our development time on the toolkit that will use them.

Numbers

Metric	Value
Total ecosystem	425K+ lines of Go
UI toolkit alone	55K lines, 208 Go files
Test functions (UI)	1,400+
Test coverage (UI)	97% average
GPU backends	5 (Vulkan, DX12, Metal, GLES, Software)
Shader targets	4 (SPIR-V, MSL, GLSL, HLSL)
Platforms	Windows, Linux (X11/Wayland), macOS
CGO required	None

Try It

# Clone and run the hello example
git clone https://github.com/gogpu/ui
cd ui/examples/hello
go run .

Requirements: Go 1.25+, a GPU with Vulkan/DX12/Metal/GLES support.

Get Involved

We're building this in the open and we want your input:

GitHub Discussions — Feature requests, architecture feedback
gogpu/ui Issues — Bug reports, widget requests
gogpu Organization — All repositories

The foundation is solid. Now comes the fun part — building the toolkit that makes Go a first-class citizen for desktop applications.

The GoGPU ecosystem is MIT-licensed. Contributions welcome.