DEV Community: Andrey Kolkov

gogpu/ui v0.1.54: We Built Flutter's Gesture System in Pure Go — Arena, Recognizers, and All

Andrey Kolkov — Thu, 13 Aug 2026 16:33:34 +0000

Series: Building Go's GPU Ecosystem

Recent articles:

Enterprise Render Pipeline — Layer Tree, Damage Tracking, 0% GPU Idle

Extracting a GPU Compositor — Patterns from Flutter and Chromium

Pure Go 3D Renderer Embedded Inside a GUI Widget

Google Says Go Is Ideal for AI-Assisted Engineering

The Problem: Every Widget Reinvented Click Detection

Our GUI toolkit has 27 widgets — buttons, checkboxes, sliders, text fields, dropdowns, dialogs, tab views, tree views, data tables, docking panels, and more — and each one implemented its own click/drag/selection logic from scratch. Button tracked pressed state. Slider tracked dragging. TextField had its own MouseDrag handler. No code was shared. No disambiguation existed.

When we wanted to add text selection to TextField (drag to select, double-click to select word, triple-click to select all), we realized the ad-hoc approach couldn't scale. What happens when a TextField is inside a ScrollView? Both want drag events. Who wins?

Flutter solved this problem in 2017 with the GestureArena. We decided to port the same architecture to Go.

What We Built

The Gesture Arena

The arena is the core disambiguation mechanism. When a pointer goes down, all widgets under the pointer register their gesture recognizers in the arena. The recognizers compete:

First to accept wins. If a recognizer is confident it detected its gesture (e.g., drag exceeded the slop threshold), it accepts and all others are rejected.
Last to not reject wins. If everyone else rejects (e.g., no movement for drag), the remaining recognizer wins by default.
Sweep after pointer up. If no one accepted, the first member wins as a last resort.

// Widget implements gesture.GestureAware
func (w *Widget) GestureHitTest(pos geometry.Point) []gesture.Recognizer {
    return []gesture.Recognizer{w.clickRec}
}

Four Recognizers + VelocityTracker

Recognizer	What it detects	Used by
ClickRecognizer	Single/double/triple click with timing	Button, Checkbox, Radio
DragRecognizer	Pan, horizontal, vertical drag with velocity	Slider, SplitView
LongPressRecognizer	Press-and-hold (500ms, frame-based)	Future: context menu
TapAndDragRecognizer	Click counting + drag in one recognizer	TextField
VelocityTracker	Least-squares velocity for fling detection	ScrollView momentum

Per-Device Thresholds

Mouse and touch have different precision. A 1px movement on a mouse is intentional; on a touchscreen it's noise. We use the same constants Flutter validated against millions of users:

Parameter	Mouse	Touch
Drag threshold (slop)	1px	18px
Double-click timeout	300ms	300ms
Double-click distance	4px (Chromium)	100px
Anti-bounce minimum	40ms	40ms

Unified Pointer Pipeline

We replaced the legacy mouse callback path with a single PointerEvent-based pipeline:

Platform → PointerEvent → HandlePointerEvent
    ├── Gesture Arena (recognizer dispatch for GestureAware widgets)
    └── Derived MouseEvent (existing widgets continue working unchanged)

Every pointer event flows through this single path. No dual dispatch. Existing widgets receive MouseEvent as before — derived from the same PointerEvent that feeds the arena.

Container Widget Hit-Testing

The hardest bug we hit: a Collapsible widget (parent) and a Checkbox (child) both had ClickRecognizers. The parent won the arena and silently dropped clicks meant for the child.

The fix: GestureHitTest(pos geometry.Point) receives widget-local coordinates. Container widgets only return recognizers when the pointer is in their interactive region:

// Collapsible returns recognizer ONLY for header clicks
func (w *Widget) GestureHitTest(pos geometry.Point) []gesture.Recognizer {
    headerRect := geometry.NewRect(0, 0, w.Bounds().Width(), w.headerHeight)
    if !headerRect.Contains(pos) {
        return nil // Content-area click → child widgets handle it
    }
    return []gesture.Recognizer{w.clickRec}
}

TextField: The Full Story

TextField was our proof-of-concept. Before v0.1.54, it could place a cursor on click. That's it. No selection, no word selection, no clipboard.

Now:

Click to place cursor (with Shift+Click for range extension)
Drag to select text character-by-character
Double-click to select word (uses wordBoundsAt() with Unicode word boundaries)
Triple-click to select all text
Double-click + drag for word-by-word selection
Ctrl+C/V/X for OS clipboard (Win32, macOS, Linux)

All of this through one TapAndDragRecognizer that provides consecutiveTapCount on every callback — exactly how Flutter's TextSelectionGestureDetector works.

OS Clipboard

We added widget.ClipboardProvider — a DI interface (same pattern as our SoundPlayer) that bridges widget clipboard requests to the platform:

// In widget package — no platform imports
widget.ClipboardWrite("copied text")
text := widget.ClipboardRead()

// Desktop layer registers the platform implementation
widget.RegisterClipboardProvider(gogpuApp) // Win32/macOS/Linux

Ctrl+C copies to system clipboard. Ctrl+V pastes from it. Works across applications.

Signals Integration

Gesture state is exposed as opt-in reactive signals:

dragRecognizer := gesture.NewDragRecognizer(gesture.DragConfig{
    OnDragStart: handleStart,
}, gesture.WithDraggingSignal(isDragging))

// Widget binds to signal for reactive redraw
state.BindToScheduler(isDragging, widget, scheduler)

Bool signals suppress no-op notifications. Point signals fire on every change. Frame-based timers (no goroutines) for long press.

Numbers

~8,300 LOC added (gesture/ package + widget migrations + clipboard + tests)
124 gesture tests, 96% coverage
20 widgets implement GestureAware with GestureHitTest
0 goroutines in the entire gesture system — single-threaded by design
5 enterprise references studied: Flutter (source code verified), Chromium, GTK4, Qt6, Android

What's Next

The gesture system is designed for multi-touch from day one. PointerEvent carries PointerID and PointerType (mouse/touch/pen). When Android support lands (@besmpl is working on it), pinch-to-zoom and multi-finger gestures will plug into the same arena.

Context menu (right-click) is the next visible feature. The gesture infrastructure supports any button — ClickRecognizer just needs a ButtonRight config.

gogpu/ui is an enterprise GUI toolkit for Go with GPU-accelerated rendering. Zero CGO, 220K+ LOC, 70 packages, 7,800+ tests.

Help Us Build Go's GUI Future

The gesture system is the kind of infrastructure that needs real-world validation. We tested with our gallery and examples, but the edge cases live in your applications.

Try it. Clone the repo, run the gallery, drag-select some text, double-click a word. If something feels wrong — file an issue. If it feels right — even better. Tell us.

git clone https://github.com/gogpu/ui.git && cd ui
GOGPU_GRAPHICS_API=vulkan go run ./examples/gallery/

Star the repo. It sounds small, but GitHub stars are how Go developers discover projects. We're listed in awesome-go — every star helps us stay there.

Spread the word. A mention in your team's Slack, a retweet, a discussion with a colleague who's frustrated with GUI options in Go. Most Go developers don't know a pure Go GUI toolkit with GPU rendering exists.

Contribute. The gesture system is designed for extensibility. Build a custom recognizer, add a new widget, improve accessibility, test on your hardware. Check CONTRIBUTING.md. @besmpl contributed 20+ PRs across the ecosystem including Android arm64 support — contributors make this project better.

Support the project. If gogpu saves you from CGO hell or fills a gap in Go's ecosystem, consider supporting on Open Collective. Open source is free to use but not free to build.

The gogpu ecosystem is 1.25M+ lines of pure Go with zero CGO. gogpu/ui alone: 220K+ LOC, 70 packages, 7,800+ tests. Five GPU backends. Three platforms. One goal: make Go the best language for building desktop applications.

GitHub · Discussions · Release v0.1.54 · awesome-go

Google Says Go Is Ideal for AI-Assisted Engineering. We've Been Proving It for a Year.

Andrey Kolkov — Wed, 12 Aug 2026 08:02:47 +0000

Yesterday Google published "Why Go is an Ideal Language for AI-Assisted Software Engineering" — arguing that AI shifted the bottleneck from writing code to reviewing it, and Go's integrated platform provides the guardrails AI teammates need.

We read it and thought: yes, we know.

Since fall 2025 we've been building Pure Go infrastructure that Go was missing — starting with HDF5 and Born ML (GPU-accelerated machine learning), then launching GoGPU in December 2025. Today it's 1.25 million lines of code. 15 repositories. Shader compiler, WebGPU implementation, 2D/3D graphics, GUI toolkit, audio engine, multi-process compositor. Zero CGO. All built using Smart Coding — our methodology where humans own architecture, specification, and review (70%), while AI handles mechanical implementation (30%), with cumulative knowledge transfer between sessions.

Here's what Google got right, what we learned the hard way, and what the article doesn't mention.

What Google Got Right

"The bottleneck shifted from writing to reviewing"

This is the central thesis, and it's correct. When AI generates hundreds of lines per session, the limiting factor becomes: can you verify this is correct?

In our workflow, every PR gets claim-by-claim validation. When a contributor submits "fix: correct PDF y-axis transform," we don't just read the diff — we verify the math:

Transform.Then applies the receiver first.
Translate(0,h).Then(Scale(1,-1)) → y' = -(y+h) ← WRONG
Scale(1,-1).Then(Translate(0,h)) → y' = h-y     ← CORRECT

We write the proof in a temp file, run it, confirm the output, then approve. AI generates the fix. Humans verify the math. Google's thesis in action.

"Go's integrated platform enables AI self-correction loops"

Google argues that gofmt, go test, go vet, and the compiler form a feedback loop where AI can iteratively fix its own output. True — and we run this loop on every change:

gofmt -w .                    # format
go build ./...                # compile (catches type errors, hallucinated APIs)
go vet ./...                  # static analysis
golangci-lint run --timeout=5m # 30+ linters
go test ./...                 # behavioral verification

Across 1.25M LOC, this catches most AI mistakes before a human ever looks at the code. The compiler is the first reviewer.

"Static types = safety net for agentic code"

Google: "If an AI agent attempts to use a non-existent method, pass an incorrect type, or leave a variable uninitialized, the code simply will not compile."

We cross-compile for three platforms on every PR:

GOOS=windows go build ./...
GOOS=linux   go build ./...
GOOS=darwin  go build ./...

This catches platform-specific hallucinations that single-platform builds miss — an AI might generate a Windows syscall in a Linux file, or reference a macOS framework in cross-platform code.

"Single static binary, zero system dependencies"

Our ecosystem proves this at scale. go build produces a binary that includes a WebGPU implementation (Vulkan/DX12/Metal/GLES/Software backends), a shader compiler (WGSL → SPIR-V/MSL/GLSL/HLSL/DXIL), a 2D graphics engine, and a GUI toolkit. No DLLs, no shared libraries, no runtime dependencies. No C compiler required.

This is what "batteries-included" means when taken seriously.

What Google Didn't Do — and We Did

Google created Go in 2009. They wrote the article about Go being ideal for AI in 2026. In between — 17 years — Go lacked three things every serious platform needs: professional graphics, GPU access, and an ML ecosystem.

No GPU graphics. No GPU-accelerated 2D library. No shader compiler. No WebGPU implementation. No GUI toolkit with native rendering. Java had Swing, then JavaFX. .NET had WPF, then MAUI. Rust got wgpu, then Bevy. Go got Fyne (CGO + OpenGL) and Ebiten (game engine, not a platform).

No GPU compute. Python has PyTorch, CUDA, TensorFlow. Rust has wgpu-rs for compute shaders and Burn for ML. Go had... os/exec to shell out to Python. A language "ideal for AI-assisted engineering" that couldn't run a GPU kernel without calling C. The irony: Google co-created the WebGPU standard (W3C) and built Dawn — the reference WebGPU implementation for Chrome. But they never gave Go access to their own standard. We built the third native WebGPU implementation in the world — and the only one in Go.

No ML ecosystem. Google writes the article about Go and AI, then builds TensorFlow in Python/C++, JAX in Python, and Gemini in... not Go. The language they praise as ideal for AI couldn't train a model.

Google builds Flutter (Dart), Android UI (Kotlin), Chrome (C++), TensorFlow (Python/C++). They never invested in making Go a first-class platform for graphics, GPU compute, or machine learning.

We're fixing all three:

Graphics: Shader compiler ahead of Rust naga on some features (DXIL generator — Rust hasn't shipped theirs). WebGPU implementation — the third in the world after Chrome's Dawn and Firefox's wgpu, and the only one in Go. GUI toolkit listed in awesome-go.
GPU compute: Born ML — a production ML framework fully migrated to our Pure Go GPU stack. Trains models on GPU. No Python, no CUDA, no CGO.
The full stack: 1.25M lines of Pure Go. From shader compilation to neural network training to GUI rendering — one language, one toolchain, go build.

Google's article validates why Go is the right language. GoGPU and Born ML prove what's possible when someone actually builds the missing pieces.

What We Learned That Google Didn't Mention

AI-generated code needs claim-by-claim validation, not just compilation

Google focuses on the compiler as the safety net. The compiler catches syntax and type errors. It does not catch:

Wrong algorithm — code compiles but produces incorrect output
Wrong architecture — code works but cements the wrong design
Wrong numbers — "renderer.go: ~720 → ~400 LOC" when the actual delta is 2,174 → 1,892

In our dev.to articles, we validate every factual claim against code before publishing. "Flutter's flow/ has ~15K LOC" — we count: actual is ~22K total lines. "ssa.Func has 30+ fields" — we count: actual is 41. "UI has 24 widgets" — we check README: actual is 27.

The compiler can't do this. Humans must.

Enterprise references prevent AI from reinventing wheels badly

Google mentions "cleaner training data" from Go's standardized ecosystem. But they don't address a deeper problem: AI confidently generates plausible-looking architecture that violates well-established patterns.

When we needed a GPU compositor, AI would happily generate a god-struct with 200 fields and bidirectional dependencies. Instead, we researched how Flutter (flow/), Chromium (cc/), and GTK4 (GSK) handle compositors. The answer was consistent: unidirectional deps, concrete structs, minimal callback interfaces. Research before code.

We formalized this as a rule: every GPU/HAL/sync/barrier change starts with enterprise reference research. AI proposes, references validate.

But references aren't always available. When you're building the third WebGPU implementation in the world, or the first Pure Go DXIL generator, there's no "how Flutter does it" to consult. You're the pioneer. AI can't help here either — it will confidently generate plausible architecture that has never been tested at scale. This is where human judgment, deep domain knowledge, and the willingness to read GPU specs directly become irreplaceable. Google's article assumes references exist. In practice, sometimes you are the reference.

Multi-agent architecture, not one AI editing everything

Google's article implies a single AI agent working on a single codebase. At our scale (15 repos), the architecture is fundamentally different.

Each repository has its own specialized agent with domain-specific sub-agents — a shader compiler agent that knows SPIR-V opcodes, a HAL backend agent that understands Vulkan barrier semantics, a GUI toolkit agent that knows widget lifecycle patterns. These agents are tuned for the specific library they serve, with their own project-level instructions, enterprise references, and research protocols.

The ecosystem-level agent only coordinates — it tracks cascade releases, manages cross-repo issues, and communicates via GitHub. It does NOT implement features in other repos. When it makes a claim ("this API should change in wgpu"), the repo-level agent independently validates that claim through its own deep research. They agree, or they push back with evidence. Very often, the first architectural instinct turns out to be fundamentally wrong — the repo agent catches it because it knows the domain deeply.

Cross-repo code changes by the coordination agent are rare exceptions, limited to thin interface seams (a new method on gpucontext.DeviceProvider, a version bump in go.mod). The real work happens inside each repo's agent session.

This isn't a preference — it's a technical necessity. No single AI agent can load 1.25M lines of code into its context window. Each repo is 96K-324K lines — already pushing context limits for a single session. The only way to work at ecosystem scale is specialized agents that deeply understand their domain, coordinated by a lightweight orchestrator that trusts but verifies.

go.work plays a different but critical role: when all repos are in a shared workspace, any agent in any repo always builds and tests against the current local state of every ecosystem dependency — not the last published version. An agent working on gg sees unpublished wgpu changes. An agent fixing a naga shader bug can immediately verify the fix compiles against the latest wgpu consumer code. No publish-wait-update cycles. When it's time for a PR or release, the code goes through multi-stage validation: each repo's agent runs its own pre-flight checks (build, test, lint across platforms, feature completeness audit, dependency freshness, documentation scan). The ecosystem agent validates cross-repo consistency. Agents check each other's claims — stubs, incomplete implementations, architectural shortcuts are caught before they reach production. And at the end, the human reviews and approves before anything is published. No release ships without explicit human sign-off.

The entire process is backed by persistent knowledge artifacts. Every deep investigation produces a research document with enterprise references and source-verified findings. Before implementation, an Architecture Decision Record (ADR) is written — documenting the decision, alternatives rejected, and enterprise patterns adopted. Kanban tasks break the work into trackable units with clear acceptance criteria.

When it's time to implement, specialized agents receive the full context — the research doc, the ADR, the task description, the relevant enterprise references. They write the code. Then the main repo agent reviews everything they produced — validates claims against code, checks for stubs, verifies test coverage, confirms the implementation matches the ADR. Only after confirming the code meets acceptance criteria does the agent approve the commit and public documentation update. If it doesn't meet the bar, the implementation iterates until it does. This is not a one-shot process — it's a quality ratchet that only moves forward.

But it's the multi-agent architecture, not go.work, that makes 15-repo AI-assisted development possible at all.

CI lint versions drift — and AI can't predict it

A practical problem Google's article doesn't address: golangci-lint latest in CI means the rules change under you. We've had PRs that pass locally (v2.12.2 on Windows, Go 1.25.5) but fail in CI (same v2.12.2, but Go 1.25.12 on Linux) because staticcheck behavior differs between Go toolchain versions.

AI generates code that passes your lint. CI runs different lint. The fix is pinning versions — but latest is the default in most GitHub Actions, including golangci-lint's own action.

The Numbers

What	Scale
Total Pure Go code	1.25M LOC
Repositories	15
GitHub stars	1,200+
Development period	~1 year (HDF5 + Born ML fall 2025, GoGPU from Dec 2025)
CGO required	Zero
External C/Rust dependencies	Zero
GPU backends	5 (Vulkan, DX12, Metal, GLES, Software)
Shader targets	5 (SPIR-V, MSL, GLSL, HLSL, DXIL)
Platforms	Windows, macOS, Linux, Browser
Contributors	8+

All built using Smart Coding — human architecture + AI implementation + cumulative knowledge — with exactly the Go guardrails Google describes.

The Ecosystem

Project	LOC	What it does
naga	324K	Shader compiler
gg	312K	2D graphics
wgpu	254K	WebGPU implementation
ui	211K	GUI toolkit (27 widgets)
gogpu	96K	App framework
+ 10 more repos	~53K	3D, audio, composition, system tray, types

Google's article is the theory. GoGPU is the proof. If you're considering Go for an AI-assisted project — we can confirm: the guardrails work. The compiler catches the easy bugs. The toolchain catches the medium bugs. Humans catch the hard bugs. And Go makes all three layers practical at scale.

But guardrails alone aren't enough. You also need a methodology — Smart Coding — where humans own the architecture, AI handles implementation, and cumulative knowledge files ensure each session builds on the last. Go provides the platform. Smart Coding provides the process.

Star us on GitHub: github.com/gogpu/gogpu ⭐

Support continued development: opencollective.com/gogpu

GoGPU: Extracting a GPU Compositor in Pure Go — Patterns from Flutter and Chromium

Andrey Kolkov — Tue, 11 Aug 2026 15:12:05 +0000

We had a suspicion the compositor was in the wrong package. But it worked, there was only one consumer, and refactoring a GPU compositor is genuinely hard. So we shipped it and moved on.

Then the 3D renderer arrived. Then the overlays broke. Suspicion turned into certainty — at the worst possible time.

This is the story of that migration, and what we learned from Flutter, Go stdlib, and Chromium along the way.

The Setup: a Compositor Hidden Inside a Drawing Library

GoGPU is a Pure Go GPU ecosystem — 1.25M lines of code, zero CGO. The architecture has three layers:

gogpu    — app framework (windowing, events, lifecycle)
gg       — 2D graphics (paths, text, GPU SDF, rasterizer)
wgpu     — WebGPU implementation (Vulkan/DX12/Metal/GLES/Software)

When we first built GPU-accelerated rendering for gg, the compositor logic naturally ended up inside gg. It was the only consumer. It owned the render target, the blit pipeline, the MSAA resolve, the damage tracking. It decided when to clear vs preserve content.

This is an ownership inversion. In every enterprise graphics stack — Chromium, Flutter, GTK4 — the compositor owns the render target and content cache. The drawing library just records draw commands into whatever surface it's given:

Framework	Drawing library	Compositor	Who owns the surface?
Chromium	Skia	cc/ (tile manager)	Compositor
GTK4	Render nodes	GSK	Compositor
Flutter	Dart Canvas	flow/	Compositor
GoGPU (before)	gg	gogpu	gg ← wrong

We suspected this wasn't right. But gg was the only renderer, it worked, and the refactoring would be complex. So we shipped it.

The Breaking Point: Three Problems, One Root Cause

Problem 1: Damage rects were single-source

Damage tracking already lived in gogpu — but as a simple passthrough. gg called SetDamageRects() with its dirty regions, gogpu forwarded them to the platform compositor via VkPresentRegionsKHR. One source, one consumer, worked fine.

Then g3d arrived. A 3D scene rotating at 60fps sends full-viewport damage. But SetDamageRects only accepted one set of rects — from gg. When gg rendered a HUD overlay on top of a g3d scene, only the HUD's damage was reported. The g3d viewport outside the HUD? Stale frames on Wayland compositors. Confirmed by @porjo on Asahi Linux (g3d#22) — visible mosaic artifacts because Mesa's wl_surface_damage_buffer only updated the HUD area.

So we redesigned the damage system from scratch. SetDamageRects (single source, simple passthrough) was replaced with RegisterDamageSource — each renderer registers as a named source, reports its own damage per frame, and gogpu unions all sources at present time. Chromium's DamageTracker uses the same union pattern. That was ADR-065 — not a refactor, a reimplementation.

Problem 2: Two overlays, two libraries

We had two independent debug overlay implementations:

gg had a damage overlay (damage_debug.go) — green flash-and-fade on dirty regions (GOGPU_DEBUG_DAMAGE)
ui had a dirty widget overlay (debug_dirty.go) — cyan rectangles on repainted widgets (GOGPU_DEBUG_DIRTY)

Both worked fine in isolation. Each had its own env var, its own rendering logic, its own fade effects. And neither knew about the other. A g3d-only app had zero debug overlays — no damage visualization, no FPS counter, nothing.

The fix: move overlays to the compositor level. A g3d-only app without gg still needs overlays. A multi-renderer app (gg + g3d) needs a unified overlay that sees damage from all sources. That was ADR-066 — a pluggable DebugOverlay system at the compositor level, with built-in damage and FPS overlays.

Problem 3: The move that broke everything

ADR-065 and ADR-066 shipped together in v0.51.0. Damage sources worked. Overlays worked — until the content was idle and the overlay had a 400ms fade animation.

1. Overlay fade: NeedsAnimationFrame() → RequestRedraw()
2. Next frame: gg says "nothing dirty" → no GPU commands
3. gg owns the render target → no commands = frame skipped
4. Overlay never draws → animation freezes

The compositor (gogpu) couldn't render overlays independently because gg owned the surface. Without gg's cooperation, the compositor couldn't even decide whether to clear or preserve the render target. The Vulkan spec says acquired swapchain images have UNDEFINED content — so without gg drawing, the overlay rendered on garbage.

Three problems, one root cause: gg owned what the compositor should own. The shortcut that "worked fine" for one consumer became a blocking architectural problem when the second and third consumers appeared. Every enterprise reference confirmed what we'd only suspected — the compositor must own the render target, not the drawing library.

Delaying further would have meant building workarounds. Each workaround would cement the wrong architecture deeper. So we stopped delaying.

Phase 1: Moving the Compositor Out of gg (ADR-067)

The first step was getting the compositor code out of gg and into gogpu where it belongs.

We introduced a compositor-owned composition texture:

Before:
  swapchain acquired → gg renders directly → present
  (gg decides Clear/Load, gg owns MSAA resolve)

After:
  swapchain acquired → gogpu clears composition texture
  → gg/g3d render INTO composition texture (they don't know)
  → gogpu draws overlays on top
  → gogpu blits composition texture → swapchain → present

Key insight: content renderers don't need to know about the compositor. Context.SurfaceView() returns the composition texture view instead of the swapchain view. From gg's perspective, nothing changed — it renders to a TextureView, same as before.

Overlay-only frames became first-class. When content is idle but an overlay is animating, the compositor uses LoadOpLoad (preserve) instead of LoadOpClear, draws the overlay on the preserved content, and presents. No cooperation from gg needed.

Phase 2: Extracting internal/compositor/ (ADR-069)

After moving compositor logic into gogpu, we had ~2,500 LOC of compositor code mixed with ~4,000 LOC of application framework in the same package. Time for the second step: extract it into internal/compositor/.

Research first

Before writing extraction code, we studied three references:

Flutter's flow/ (~22K lines) — concrete structs, unidirectional deps (shell/ → flow/, never reverse), GPU resources borrowed per frame through a callback. Closest to our situation.

Go stdlib ssa.Func (41 fields) — the largest internal/ split in Go. Struct ownership + Frontend callback interface. Parent creates the struct, calls methods. Internal package calls back through a minimal interface when it needs the parent.

Chromium cc/ (~190K lines) — interface-heavy dependency injection with *Client/*Delegate abstract classes everywhere. A C++ necessity, over-engineered for Go internal/.

What we actually built

The compositor isn't a single god-struct. It's a set of focused types that the root package composes:

gogpu/ (root package, renderer.go)
│
├── RenderTarget {
│     damageSources  []*compositor.DamageSource
│     blitPipeline    compositor.BlitPipeline
│     compositeState  compositor.CompositeState
│   }
│
└── internal/compositor/
    ├── blit.go            — BlitResources, BlitDrawRecorder interface
    ├── blit_pipeline.go   — BlitPipeline, CompositeState
    ├── damage_source.go   — DamageSource, per-renderer damage tracking
    ├── damage_scissor.go  — pure geometry: rect union, scissor clipping
    ├── damage_overlay.go  — DamageDebugOverlay (damage rect visualization)
    ├── fps_overlay.go     — FPSDebugOverlay (frame rate counter)
    ├── overlay_pipeline.go — shared GPU pipeline for overlays
    └── shader.go          — WGSL shader sources

Content renderers (gg, g3d) implement one interface:

type BlitDrawRecorder interface {
    RecordBlitDraws(pass *wgpu.RenderPassEncoder)
}

The compositor owns the render pass lifecycle. Renderers just record their draws.

The numbers

renderer.go: 2,174 → 1,892 lines (-282 LOC of compositor logic removed)
internal/compositor/: 2,357 LOC (self-contained subsystem)
Root package wiring: 194 LOC (thin delegation)

Zero public API change. All App, Context, RenderTarget types stayed in the root package. RegisterDamageSource() return type narrowed to gpucontext.DamageReporter interface — which external consumers already used. No breaking change.

Rules That Emerged

These are now enforced in CI:

1. No type aliases for migrated types. type X = internal.X is for transitional migration only. We changed return types to interfaces instead.

2. Call internal directly. No unexported wrapper functions around internal/ calls. At call sites: r.blitPipeline.Init(device, format, shader), not an unexported initBlitPipeline() wrapper.

3. Unidirectional deps, enforced in CI:

- name: Compositor dependency direction
  run: |
    if grep -r '"github.com/gogpu/gogpu"' internal/compositor/; then
      echo "compositor must not import root package"
      exit 1
    fi

4. Performance is not a reason to avoid extraction. We benchmarked interface calls: ~1.4-3.0ns vs ~1.3ns for direct calls. At 10 calls/frame × 60fps = ~60ns per frame vs ~16.7ms budget. 0.0005% overhead. Go 1.20+ devirtualizes most of these anyway.

What We Learned

"We'll fix it later" has a deadline you don't control. We suspected the compositor was in the wrong place for months. The deadline to fix it wasn't set by us — it was set by the overlay freeze bug and the 3D renderer needing damage tracking. Under pressure, every refactoring is harder.

Enterprise references agree on ownership. We checked Chromium, Flutter, and GTK4. In all three, the compositor owns the surface and content cache. The drawing library just draws. This isn't a coincidence — it's the architecture that survives multi-renderer apps.

Not everything needs a god struct. The Go stdlib ssa.Func pattern (single struct, 40+ fields, callback interface) is powerful but not universal. Our compositor worked better as a set of focused types (3-8 fields each) that the root package composes. Each type has a clear responsibility.

internal/ is underrated. Most Go projects either put everything in one package or create deep hierarchies. internal/ gives you encapsulation without the API commitment. The compositor is free to change its struct layout without breaking external consumers.

The Ecosystem

GoGPU is 1.25M lines of Pure Go — a full GPU ecosystem, not just one library:

Project	LOC	What it does
naga	324K	Shader compiler (WGSL → SPIR-V/MSL/GLSL/HLSL/DXIL)
gg	312K	2D graphics (Skia-class rasterizer, GPU SDF, ClearType)
wgpu	254K	WebGPU (Vulkan/DX12/Metal/GLES/Software/Browser)
ui	211K	GUI toolkit (27 widgets, 4 design systems)
gogpu	96K	App framework + compositor
g3d	14K	3D rendering (scene graph, PBR, forward renderer)
compose	10K	Multi-process composition (Unix socket, LZ4, hot-plug)
systray	8K	System tray (Win32/macOS/Linux, zero CGO)
audio	3.5K	Audio engine (WASAPI, WAV, Mixer)

Zero CGO. go build and it works. Windows, macOS, Linux, Browser.

1,200+ GitHub stars. Listed in awesome-go. Used by Born ML for GPU compute, ironwail-go for Quake 1 rendering.

The compositor migration landed across three releases: v0.51.0 (ADR-065 + ADR-066, damage source reimplementation + pluggable overlays), v0.52.0 (ADR-067, compositor-owned render target), and v0.52.1 (ADR-069, package extraction).

If your drawing library owns compositor state and you only have one consumer — fix it now. The second consumer always arrives sooner than you expect.

Try It, Break It, Tell Us

GoGPU is pre-v1.0 — this is the best time to influence the API before it freezes. We need your help:

Test on your hardware. We develop on Intel Iris Xe (Windows) and Mesa llvmpipe (Linux). AMD, NVIDIA, Apple Silicon, Adreno — every GPU we haven't tested is a bug we haven't found. Run the examples, file issues.
Contribute. PRs welcome — from typo fixes to new backends. We review everything. Check good first issues across the org.
Write about it. Tutorials, reviews, comparisons — in any language. Pavel Tišnovský wrote three parts on root.cz (Czech), covering gg 2D graphics and gogpu windowing with 12 interactive examples. If you write something, let us know — we'll link it.
Spread the word. Star us, mention us in your talks, recommend us when someone asks "how do I do GPU in Go?"

Support the Project

GoGPU is built by a small team in their spare time. If you find it useful, consider supporting continued development:

Support GoGPU on Open Collective — every contribution helps us spend more time on the ecosystem instead of client work.

Star us on GitHub: github.com/gogpu/gogpu ⭐

We Built a Pure Go 3D Renderer — Then Embedded It Inside a GUI Widget

Andrey Kolkov — Sun, 02 Aug 2026 21:33:11 +0000

Go has had a 2D graphics story for a while now. But 3D? The options have been either CGO wrappers around OpenGL, abandoned projects from 2019, or "use Ebiten and write your own engine."

We decided to build the missing piece: g3d — a Pure Go 3D rendering library with scene graph, PBR materials, and forward rendering pipeline. Zero CGO, all five GPU backends (Vulkan, Metal, DX12, GLES, Software), 374 tests, built on our WebGPU implementation.

But a 3D renderer that only works standalone is half the story. The real question is: how does it compose with UI?

This post covers the two integration patterns we shipped in v0.1.4 — patterns that every enterprise 3D application uses, from Unity to Blender to CAD tools. And how we filed eight cross-repo issues across five repositories to make it work.

The 20-Line Rotating Cube

Before we get to integration — here's what g3d looks like standalone:

scene := g3d.NewScene()
scene.SetBackground(g3d.RGB(0.1, 0.1, 0.15))

sun := g3d.NewDirectionalLight(
    g3d.WithLightColor(g3d.White),
    g3d.WithLightIntensity(1.0),
)
scene.Add(sun.LightNode())

cube := g3d.NewMesh(
    g3d.NewBoxGeometry(1, 1, 1),
    g3d.NewStandardMaterial(
        g3d.WithColor(g3d.RGB(0.4, 0.7, 1.0)),
        g3d.WithRoughness(0.6),
    ),
)
scene.Add(cube.MeshNode())

camera := g3d.NewPerspectiveCamera(75, 800.0/600.0, 0.1, 1000)
camera.CameraNode().SetPosition(g3d.Vec3{X: 0, Y: 0.5, Z: 3})

Scene graph, PBR materials, directional lighting — all CPU data structures. No GPU device needed until you render. The API is inspired by Three.js, but idiomatic Go: interfaces + functional options, not OOP inheritance chains.

The renderer creates itself lazily on first frame:

app.OnDraw(func(dc *gogpu.Context) {
    if renderer == nil {
        renderer, _ = g3d.NewRenderer(app.GPUContextProvider())
    }
    renderer.Render(scene, camera, dc.SurfaceView())
})

That's it. Rotating PBR cube on Vulkan. Single binary, zero CGO, go build && ./app.

The Real Challenge: 3D + UI

A standalone 3D window is a demo. A 3D viewport inside a GUI application — that's a product. Think about what real 3D applications look like:

Game: fullscreen 3D world with health bar, minimap, crosshair overlaid
CAD tool: 3D model viewer with toolbar, property panel, status bar around it
IDE: 3D preview panel embedded alongside code editor and file tree

These are two fundamentally different composition patterns:

Pattern	3D Renders To	UI Renders To	Who Owns the Surface
Fullscreen overlay	Swapchain directly	Same swapchain (on top)	Both, sequentially
Embedded widget	Offscreen texture	Swapchain (compositor)	UI framework

We implemented both. And both required solving problems that no Go project had solved before.

Pattern 1: Fullscreen 3D + 2D Overlay

This is the game/CAD pattern. g3d renders the 3D scene to fill the entire window, then gg (our 2D graphics library) draws HUD elements on top: title, FPS counter, crosshair, status bar.

The enterprise pattern is well-established — we researched seven engines:

Engine	How They Do It
Bevy + egui	Separate render pass, `LoadOp::Load`, `depth_stencil: None`
Dear ImGui	Separate render pass, `DepthEnable=false`, alpha blending
Unity	Screen Space Overlay canvas, rendered after everything
Godot	CanvasLayer, separate from 3D viewport
Three.js	`clearDepth()` between 3D and HUD render calls

The universal answer: two render passes on the same surface. First pass clears and renders 3D with depth testing. Second pass loads the existing content and renders 2D with alpha blending, no depth.

In g3d + gogpu + gg, this looks like:

app.OnDraw(func(dc *gogpu.Context) {
    // Pass 1: g3d renders 3D scene (LoadOp::Clear + depth)
    renderer.Render(scene, camera, dc.SurfaceView())

    // Bridge: tell gogpu the surface has content
    dc.MarkExternalContent()

    // Pass 2: gg renders 2D HUD (LoadOp::Load + alpha blend)
    canvas.Draw(func(cc *gg.Context) {
        drawHUD(cc, width, height, fps)
    })
    canvas.Render(dc.RenderTarget())
})

MarkExternalContent() is the key API. It tells the gogpu framework: "someone already rendered to this surface — don't clear it." Without this call, gg's render pass would wipe the 3D scene with LoadOp::Clear. With it, gg uses LoadOp::Load and draws transparently on top.

This is the same concept as Qt's beginExternal()/endExternal(), Flutter's InlinePassContext, and Unity's Camera.DontClear.

The Result

A rotating PBR cube at 60 FPS with a full HUD overlay — title, live FPS counter, animated crosshair, status bar with backend info. All Pure Go, all on the same swapchain, zero copies.

GOGPU_GRAPHICS_API=vulkan go run ./examples/fullscreen-overlay/

Pattern 2: 3D Inside a GUI Widget

This is the CAD/IDE pattern. The 3D viewport is one widget among many — surrounded by buttons, text, panels. The UI framework owns the window; g3d renders into an offscreen GPU texture; the compositor blits it into the widget tree.

This is how Qt's QRhiWidget, Unity's RenderTexture, and Godot's SubViewport work.

In g3d + gogpu/ui:

vp := gpuview.New(
    gpuview.Size(600, 400),
    gpuview.Continuous(true),
    gpuview.OnRender(func(view gpucontext.TextureView) {
        wgpuView := (*wgpu.TextureView)(view.Pointer())
        renderer.Render(scene, camera, wgpuView)
    }),
)

The gpuview.Widget (formerly Viewport3D, renamed for universality) handles the GPU texture lifecycle. It creates an offscreen texture, passes it to your OnRender callback, and hands the result to the Layer Tree compositor for blitting into the final frame.

Your 3D renderer doesn't know or care that it's inside a widget. It receives a TextureView and renders to it — same API as fullscreen rendering.

The UI layout is standard gogpu/ui:

uiApp.SetRoot(primitives.Box(
    primitives.Text("g3d GPUView").FontSize(22).Bold(),
    vp, // 3D viewport widget
    button.New(
        button.TextOpt("Pause / Resume"),
        button.OnClick(func() { paused = !paused }),
    ),
).Padding(28).Gap(14).Rounded(12).ShadowLevel(2))

Material 3 themed card with a 3D viewport, title, and control buttons. The 3D content renders at GPU speed inside the widget while the rest of the UI renders through the standard compositor pipeline.

go run ./examples/viewport3d/

Eight Issues Across Five Repos

Getting both patterns working wasn't just API design — it was a debugging marathon across five repositories (g3d, gg, gogpu, ui, wgpu) and eight issues. Here are the three hardest:

Bug 1: MSAA Resolve Overwrites External Content

When gg renders its 2D overlay, it uses 4x MSAA for antialiased edges. The MSAA render pass writes to an intermediate texture, then resolves to the swapchain. The resolve is a full overwrite — it doesn't care what was on the swapchain before.

So even with LoadOp::Load, the MSAA intermediate texture was empty (it never contained the 3D scene), and the resolve wrote empty + HUD to the swapchain. 3D content gone.

Fix: gg v0.50.9 implemented Strategy C from Skia's playbook — render the overlay into a separate offscreen MSAA texture, resolve to a 1x intermediate with alpha, then alpha-blend composite onto the swapchain via textured quad. The 3D content survives because the swapchain is never a resolve target.

Bug 2: GPU Buffer Use-After-Free

g3d's renderer created uniform buffers per frame with MappedAtCreation, used them in a render pass, submitted the command buffer, and immediately released them via defer. But queue.Submit() is asynchronous — the GPU was still reading the buffers when Go freed them.

command buffer at index 0 references released buffer "g3d_frame_uniforms"

Fix: Replaced per-frame allocation with persistent uniform buffers updated via queue.WriteBuffer(). Geometry buffers cached by identity. Bind groups deferred-released at the start of the next frame. This is the same pattern gg uses internally — zero allocations in the hot path.

Bug 3: Layer Tree Missing External Texture Node

The gpuview widget created its texture, fired OnRender, and g3d rendered into it correctly. But the widget was invisible. The Layer Tree compositor had ExternalTextureLayer support in its rendering code — but nobody created those nodes.

buildBoundaryLayer() only created PictureLayer nodes. Widgets with external GPU textures needed a parallel ExternalTextureLayer node so the compositor would blit their content.

Fix: ui v0.1.49 added externalTextureWidget interface detection in the Layer Tree builder. Widgets that provide Texture() and ViewportSize() automatically get an ExternalTextureLayer alongside their PictureLayer.

Shared Command Encoder: The Third Way

Sometimes you don't want two separate queue.Submit() calls. g3d v0.1.3 added RenderTo() — record g3d render passes into a caller-owned command encoder:

encoder, _ := device.CreateCommandEncoder(nil)

// g3d records its render pass
renderer.RenderTo(encoder, scene, camera, targetView)

// Other renderers record their passes
overlayRenderer.RecordTo(encoder, ...)

// One submit for the entire frame
commands, _ := encoder.Finish()
queue.Submit(commands)

This eliminates the multi-submit overhead and gives you precise control over render pass ordering. It's the pattern gogpu v0.48.4 uses internally via dc.CommandEncoder().

The Architecture

Here's how g3d fits into the gogpu ecosystem:

Your Application
    ├── gogpu (window + GPU device)
    ├── g3d  (3D scene → render passes)
    ├── gg   (2D graphics → render passes)
    └── ui   (widget tree → compositor → render passes)
              └── gpuview widget ← g3d renders here

g3d depends down only — on wgpu and gpucontext. Never on gogpu, gg, or ui. This means you can use g3d in any context: with gogpu, with your own windowing, or headless for testing.

The shared GPU device comes through gpucontext.DeviceProvider — the same database/sql-style interface pattern that gg, ui, and Born ML use. One device, shared across all renderers, zero-copy resource sharing.

The Ecosystem Is Accelerating

g3d doesn't exist in isolation. The gogpu ecosystem is growing in directions that directly benefit 3D applications:

Zero-CGO Android. @besmpl proved that CGO_ENABLED=0 -buildmode=c-shared works on Android arm64 via //go:nativeexport — a Go toolchain patch that eliminates the last CGO dependency for mobile GPU apps. The prototype runs on API 30 emulator. Once upstream, g3d will run on Android with the same go build simplicity as desktop.

Pure Go Race Detector. The GoGPU ecosystem can't use go test -race today because GPU backends require CGO_ENABLED=0. We're contributing to a Pure Go race detector that achieves read-path parity with TSAN (0.985x on Apple M1). @besmpl delivered 20 optimization commits in 5 days. When merged, every GPU-accelerated Go project gets race detection for free.

Browser/WASM. wgpu's triple-backend architecture (ADR-038) means g3d will run in the browser via WebGPU — same Go code, GOOS=js GOARCH=wasm go build. The browser backend is already shipping in wgpu for 2D; 3D follows the same path.

Composition library. gogpu/compose enables multi-process GPU composition — think VS Code's renderer process architecture, but for Go. A g3d viewport in one process, a 2D editor in another, composited via Unix socket + LZ4.

Community tutorials. Pavel Tišnovský (2,185+ articles on root.cz, Czech Republic) published 88 minutes of tutorial content covering the ecosystem with 54 working examples — the first serious European press coverage of Go GPU graphics.

Games are happening. @kivutar built Goro — a Ragnarok Online client using gogpu/ui in Pure Go (no CGO), with working UI, mercenaries, and gameplay. @darkliquid's Quake 1 port runs on our Vulkan stack. The Go game dev community is real — and it needs a 3D library that doesn't require CGO.

By the Numbers

Metric	Value
g3d LOC	~11,700
Tests	374
GPU backends	5 (Vulkan, Metal, DX12, GLES, Software)
Examples	3 (hello-cube, fullscreen-overlay, viewport3d)
Cross-repo bugs found	8
Cross-repo bugs fixed	8
Releases	3 (v0.1.2 → v0.1.4, Jul 26 – Aug 2)
Ecosystem total	1.2M+ LOC Pure Go

Try It

# Standalone 3D
go run github.com/gogpu/g3d/examples/hello-cube@latest

# Fullscreen 3D + 2D overlay
go run github.com/gogpu/g3d/examples/fullscreen-overlay@latest

# 3D inside UI widget
go run github.com/gogpu/g3d/examples/viewport3d@latest

Select your GPU backend:

GOGPU_GRAPHICS_API=vulkan   go run ./examples/hello-cube/
GOGPU_GRAPHICS_API=dx12     go run ./examples/hello-cube/
GOGPU_GRAPHICS_API=software go run ./examples/hello-cube/

What's Next

g3d v0.1.4 has the foundation: scene graph, PBR materials, forward renderer, and two production-ready integration patterns. Here's what's coming:

Phase 2 — Real Materials. Cook-Torrance BRDF replaces Blinn-Phong. Shadow mapping (directional + point). Normal maps, metallic/roughness textures, emissive maps. This is where g3d goes from "demo-ready" to "product-ready."

Phase 3 — GLTF 2.0. Binary .glb and JSON .gltf loading with PBR materials, skeletal animation, and morph targets. GLTF is the "JPEG of 3D" — every modeling tool exports it, every engine imports it. g3d will too.

Phase 4 — Scale. Instance batching for thousands of objects. Environment maps for reflections. Post-processing pipeline (bloom, tone mapping, FXAA). Skybox.

Phase 5 — Performance. BVH-accelerated frustum culling, LOD (level of detail), SIMD math via Go 1.25+ goexperiment.simd. The GoMLX PackGEMM team proved 14x speedup with Pure Go AVX-512 — same approach applies to matrix math.

The rendering library was the last missing piece in Go's graphics ecosystem. 2D graphics, GUI toolkit, shader compiler, audio engine, system tray — all Pure Go, all shipping. Now 3D joins them.

How You Can Help

This project grows through real-world usage. Every bug report from a different GPU, every feature request from a real application, every "it works on my AMD/NVIDIA/Apple M4" — that's data we can't generate alone.

Test it on your hardware. We develop on Intel Iris Xe. AMD, NVIDIA, Apple Silicon, Adreno — we need your GPU. A simple go run ./examples/hello-cube/ and a one-line issue "works on RTX 4080 / Vulkan" is genuinely valuable.

Build something with it. A 3D file viewer. A data visualizer. A game prototype. A CAD preview panel. The API is designed to be embedded — g3d doesn't own your application, you own g3d. The integration patterns in this article work today.

Report what's missing. We're tracking Phase 2–5 features, but priority depends on what people actually need. Shadows? GLTF? Instance batching? Textures? Tell us.

Spread the word. Star the repos, share the examples, write about your experience. Go's graphics ecosystem has been invisible for 17 years because nobody knew it existed. That changes when the community talks about it.

Contribute code. The CONTRIBUTING.md has everything you need. Good first issues are labeled. We review PRs within 24 hours. Every contributor gets credit in the CHANGELOG and release notes.

Support the project. We accept donations via Open Collective to fund development, testing on diverse GPU hardware, and CI infrastructure. Every contribution helps us test on more platforms and ship faster.

The ecosystem is 1.2M+ lines of Pure Go — but the codebase isn't what makes it real. Users make it real. Applications make it real. The more people building on g3d, the faster it reaches the quality bar that Go deserves.

Go's sql.Null[T] Will Never Get JSON Support. Here's What We Built Instead.

Andrey Kolkov — Sat, 04 Jul 2026 18:52:37 +0000

Go 1.22 gave us sql.Null[T] — a generic nullable type for SQL. Problem solved?

No. Try marshaling it to JSON:

{"V":"Alice","Valid":true}

That's not "Alice". That's not null. That's a broken API response.

And it will never be fixed. Issue #68375 — proposal to add MarshalJSON to sql.Null[T] — was closed as infeasible. Go's policy forbids adding marshal methods to types that already have a "reasonable" default marshaling. The struct marshaling {"V":...,"Valid":...} counts as "reasonable."

This is a permanent gap in Go's standard library.

The Three Bad Options (Before opt)

1. `sql.Null[T]` — SQL works, JSON broken

type User struct {
    Name sql.Null[string] `json:"name"`
}
// Marshals to: {"name":{"V":"Alice","Valid":true}}
// You wanted:  {"name":"Alice"}

2. `*string` — JSON works, everything else is awkward

type User struct {
    Name *string `json:"name"`
}
// Pointer allocation overhead on every value
// Can't distinguish "field absent" from "field is null"
// user.Name == nil — is this "not set" or "set to null"?

3. `guregu/null` — Works, but carries 10 years of legacy

guregu/null (2,070 stars) is the de facto standard. It works. But:

v1→v6 legacy — API evolved over 10 years, backward compatibility constraints
No three-state — can't distinguish "field absent" from "field null" (critical for PATCH APIs)
No Map/FlatMap — no functional composition
No OrNull constructors — every project writes the same boilerplate helpers
Generic Value[T] has MarshalText and Equal commented out — couldn't make them work generically

opt: Option<T> for Go

coregx/opt — designed from scratch for Go 1.24+. No legacy, no compromises.

import "github.com/coregx/opt"

type User struct {
    Name  opt.String `json:"name"`
    Email opt.String `json:"email,omitzero"`
    Age   opt.Int    `json:"age"`
}

user := User{
    Name: opt.StringFrom("Alice"),
    Age:  opt.IntOrNull(0),  // 0 means "not set" → null
}

data, _ := json.Marshal(user)
// {"name":"Alice","age":null}
// Email omitted (omitzero) — not null, just absent

JSON works. SQL works. No pointer overhead. No boilerplate.

What Makes opt Different

1. Three-State `Field[T]` — The PATCH API Killer Feature

Every REST API with PATCH endpoints has this problem: how do you distinguish "the client didn't send this field" from "the client explicitly set it to null"?

type PatchUser struct {
    Name  opt.Field[string] `json:"name,omitzero"`
    Email opt.Field[string] `json:"email,omitzero"`
    Age   opt.Field[int]    `json:"age,omitzero"`
}

// Client sends: {"name":"John","email":null}
var patch PatchUser
json.Unmarshal(input, &patch)

patch.Name.IsValue()   // true  → set name to "John"
patch.Email.IsNull()   // true  → set email to NULL in DB
patch.Age.IsAbsent()   // true  → don't touch age

Three states: absent (don't touch), null (set to NULL), value (set to value).

Rust does this with Option<Option<T>>. Kotlin with nullable + optional. In Go, no library properly solves this — guregu/null doesn't distinguish absent from null, and pointer-based approaches (**T) are impractical. coregx/opt's Field[T] is the first clean solution with concrete typed constructors, OrNull, FlatMap, and a zero/ subpackage.

2. `OrNull` Constructors — No More Boilerplate

Every project using nullable types with a database writes the same helpers:

// This is in EVERY Go project with nullable DB fields
func optStr(s string) opt.String {
    return opt.NewString(s, s != "")
}
func optInt(n int64) opt.Int {
    if n == 0 { return opt.Int{} }
    return opt.IntFrom(n)
}

With opt, this is built in:

row := CompanyRow{
    City: opt.StringOrNull(company.City()),     // "" → null
    OGRN: opt.StringOrNull(reg.OGRN()),         // "" → null
    Count: opt.IntOrNull(company.EmployeeCount()), // 0 → null
}

One function per type. Zero boilerplate. Available for all 8 concrete types including BoolOrNull.

3. Functional API — Map, FlatMap, Equal

Inspired by Rust's Option<T>:

// Transform if valid, propagate null
name := opt.From("  Alice  ")
trimmed := opt.Map(name, strings.TrimSpace)    // opt.Option[string]{"Alice", true}
length := opt.Map(trimmed, func(s string) int { return len(s) })  // opt.Option[int]{5, true}

// Chain operations that may produce null
parsed := opt.FlatMap(input, func(s string) opt.Option[int] {
    n, err := strconv.Atoi(s)
    if err != nil { return opt.New(0, false) }
    return opt.From(n)
})

// Nil-safe comparison
opt.Equal(opt.From(42), opt.From(42))  // true
opt.Equal(opt.From(42), opt.New(0, false))  // false

guregu/null has ValueOr. That's it. No Map, no FlatMap, no OrElse.

4. Generic `Option[T]` That Actually Works

guregu's generic Value[T] has MarshalText and Equal commented out in the source code — they couldn't make them work generically.

opt's Option[T] is fully functional:

// Works with ANY type
v := opt.From(MyCustomStruct{Name: "test"})
data, _ := json.Marshal(v)  // {"Name":"test"}

null := opt.New(MyCustomStruct{}, false)
data, _ = json.Marshal(null)  // null

5. `zero/` Subpackage — Alternative Semantics

Sometimes you want zero values to be null, and null to marshal as zero (not null):

import "github.com/coregx/opt/zero"

s := zero.StringFrom("")   // Invalid — empty = null
data, _ := json.Marshal(s) // "" (not "null")

i := zero.IntFrom(0)       // Invalid — 0 = null
data, _ = json.Marshal(i)  // 0 (not "null")

Package	`From("")`	Marshal null
`opt`	Valid (empty string)	`null`
`opt/zero`	Invalid (null)	`""`

Comparison

Feature	coregx/opt	guregu/null	`*T`	`sql.Null[T]`
Generic nullable	`Option[T]`	Partial	N/A	No JSON
Three-state (PATCH)	`Field[T]`	No	No	No
Concrete types (String, Int...)	8 types	8 types	N/A	N/A
`OrNull` constructors	Yes	No	No	No
`FieldFromOption`	Yes	No	No	No
Map / FlatMap	Yes	No	No	No
OrElse (lazy)	Yes	No	No	No
Equal	Yes	Yes	N/A	No
JSON marshal	Yes	Yes	Yes	Broken
SQL Scanner/Valuer	Yes	Yes	Yes	Yes
omitzero (Go 1.24+)	Yes	Yes	No	No
zero-is-null subpackage	`zero/`	`zero/`	No	No
json/v2 compatible	Yes	Yes	Yes	No
Legacy code	None	v1→v6	N/A	N/A

Performance

Zero-allocation unmarshal. Bool operations under 2 nanoseconds:

BenchmarkBoolMarshalJSON     0.85 ns/op    0 allocs
BenchmarkBoolUnmarshalJSON   2.1 ns/op     0 allocs
BenchmarkIntUnmarshalJSON    193 ns/op     1 alloc
BenchmarkStringUnmarshalJSON 137 ns/op     0 allocs
BenchmarkStructMarshalJSON   876 ns/op     9 allocs

Why New Projects Should Start with opt

sql.Null[T] will never get JSON support — this is official Go team position (#68375)
*T can't do three-state — nil means both "absent" and "null"
guregu/null works but carries v1→v6 legacy and has no PATCH support
opt starts clean — Go 1.24+, generics-first, no backward compatibility burden
Field[T] is unique — no other Go library properly solves the PATCH three-state problem
Zero dependencies — only Go stdlib
json/v2 ready — works today, optimizable when json/v2 goes stable

Getting Started

go get github.com/coregx/opt@v0.3.0

import "github.com/coregx/opt"

// Always valid
name := opt.StringFrom("Alice")

// Zero means "not set"
age := opt.IntOrNull(0)  // null

// From pointer (nil → null)
email := opt.StringFromPtr(emailPtr)

// Three-state for PATCH
type PatchRequest struct {
    Bio opt.Field[string] `json:"bio,omitzero"`
}

Full API and examples: github.com/coregx/opt

Help Us Get to v1.0.0

opt is in active development. We're heading toward a stable v1.0.0 and need your help:

Try it in your project — replace *string or guregu/null and tell us how it goes
Report issues — edge cases, driver compatibility, unexpected behavior
Suggest features — what nullable types should do that no library does yet
Send PRs — new types, better tests, documentation improvements
Share — if opt solved a problem for you, tell your team or write about it

Every bug report, feature idea, and PR brings us closer to a stable API.

GitHub | Issues | pkg.go.dev

opt is part of the coregx ecosystem — high-performance Go libraries for production applications.

Stop Concatenating SQL Strings in Go — Dynamic Queries Done Right

Andrey Kolkov — Fri, 03 Jul 2026 18:07:36 +0000

This is a follow-up to my earlier article about Relica — a zero-dependency SQL query builder for Go. Since then, we've shipped a major v0.12.0 release with comprehensive security hardening, zero-panic guarantee, and integration tests on all three databases. But today I want to talk about the real problem — the one that made me build Relica in the first place.

If you've built an API with filterable endpoints in Go, you've written code like this:

query := "SELECT * FROM products WHERE 1=1"
args := []interface{}{}

if req.Category != "" {
    query += " AND category = $" + strconv.Itoa(len(args)+1)
    args = append(args, req.Category)
}
if req.MinPrice > 0 {
    query += " AND price >= $" + strconv.Itoa(len(args)+1)
    args = append(args, req.MinPrice)
}
if req.InStock {
    query += " AND stock > 0"
}

The infamous WHERE 1=1 hack. Manual placeholder numbering that breaks when you reorder conditions. String concatenation that smells like SQL injection. And when you switch from PostgreSQL ($1, $2) to MySQL (?, ?) — you rewrite every single query.

I've been writing Go for production systems since 2019, and this pattern shows up in every codebase I've worked on. It's the single most common SQL pain point in the Go ecosystem, and in 2026, the mainstream libraries still don't solve it cleanly.

Let me show you why — and what I did about it.

Why Every Go SQL Library Gets Dynamic Queries Wrong

The sqlc problem: static by design

sqlc is brilliant for what it does — generating type-safe Go code from SQL. But dynamic queries? That's been the #1 feature request since 2020, with 150+ reactions and dozens of comments — still unresolved.

The official workaround looks like this:

-- Optional filter in sqlc
SELECT * FROM products
WHERE (NOT @has_category::boolean OR category = @category)
  AND (NOT @has_min_price::boolean OR price >= @min_price);

You're writing more SQL, not less. And this pattern defeats index optimization — PostgreSQL can't use a category index when the condition is wrapped in NOT @has_category OR ....

If your API has 8 optional filters, you get 8 boolean parameters and 8 CASE-like conditions. It's not scalable.

The sqlx problem: no builder, no maintainer

sqlx extends database/sql with struct scanning — and that's it. No query builder. Dynamic queries mean string concatenation, exactly like raw database/sql.

But here's the bigger problem: sqlx is effectively abandoned. Multiple issues (#883, #969) ask "is this project dead?" with no response. A community fork was created in March 2025 because "the original project has been inactive for several years."

Building production systems on an abandoned library is a ticking time bomb.

The GORM problem: magic without transparency

GORM handles dynamic queries well — db.Where("category = ?", cat).Where("price >= ?", min) works naturally. But GORM's abstractions come with hidden costs that surface in production:

The zero-value gotcha:

// GORM silently ignores zero-value fields
db.Where(&Product{Price: 0}).Find(&products)
// Generated: SELECT * FROM products
// Expected:  SELECT * FROM products WHERE price = 0

GORM skips Price: 0 because Go's zero value for int is 0. Your query returns all products when you wanted free ones. This has burned countless developers.

Hidden N+1 queries:
Fetching 100 orders with customer data? GORM might fire 101 queries — one for orders, one per customer. You won't know until your p99 latency spikes from 2ms to 6 seconds under load. The SQL is hidden behind layers of reflection.

And it brings external dependencies into your go.sum — GORM core plus a driver means multiple transitive packages. Each one is a potential supply chain vulnerability, a version conflict, a breaking change in an update.

The squirrel problem: unmaintained and unsafe

squirrel was once the go-to Go query builder. But it has 96 open issues, no releases since 2023, and a known security issue with unsafe identifier quoting. The maintainer explicitly stated they "will not necessarily respond" to bug reports.

What Go Developers Actually Want

The Go community keeps having the same debate: ORM vs raw SQL. But both sides want the same thing — convenience without losing control.

The requirements are clear:

Dynamic query builder — composable WHERE conditions without string concatenation
Transparent SQL — see exactly what's being sent to the database
Zero magic — no hidden queries, no zero-value gotchas, no reflection surprises
Minimal dependencies — ideally zero in production
Multi-database — same API for PostgreSQL, MySQL, SQLite

This is exactly why I built Relica.

Some context: ozzo-dbx by Qiang Xue (creator of the Yii framework) was one of the best-designed Go query builders — clean Expression API, composable WHERE clauses, struct scanning without ORM magic. But it was built in 2015-2016 and hasn't been updated for modern Go.

Qiang just gave me full maintainer rights to the entire go-ozzo ecosystem. I've been maintaining Relica as ozzo-dbx's successor — rebuilt from scratch with Go 1.21+, zero production dependencies, and comprehensive security hardening that the original never had.

If you used ozzo-dbx and loved the design but wished someone was keeping the lights on — Relica is what it was always meant to become.

Building Dynamic Queries Without String Concatenation

Here's that same filtering problem with Relica's Expression API:

q := db.Select("id", "name", "price", "category").From("products")

if req.Category != "" {
    q = q.Where(relica.Eq("category", req.Category))
}
if req.MinPrice > 0 {
    q = q.Where(relica.GreaterOrEqual("price", req.MinPrice))
}
if req.MaxPrice > 0 {
    q = q.Where(relica.LessOrEqual("price", req.MaxPrice))
}
if req.InStock {
    q = q.Where(relica.GreaterThan("stock", 0))
}

var products []Product
err := q.All(&products)

No WHERE 1=1. No placeholder numbering. No string concatenation. Each .Where() call adds an AND condition — conditions compose naturally.

Column names are automatically quoted for your dialect ("price" for PostgreSQL, `price` for MySQL). Values are always parameterized — SQL injection is structurally impossible through the Expression API.

And switching databases? Change the connection string. The query code is identical.

See the SQL Before You Run It

Unlike GORM, you always know what SQL Relica generates:

sql, params := q.ToSQL()
fmt.Println(sql)
// PostgreSQL: SELECT "id", "name", "price", "category"
//   FROM "products"
//   WHERE "category" = $1 AND "price" >= $2 AND "stock" > $3

fmt.Println(params)
// [electronics 100 0]

ToSQL() works on all six query types — SELECT, INSERT, UPDATE, DELETE, UPSERT, and BatchInsert. In development, log every query. In production, use it for debugging slow queries. No guessing, no Debug mode — just call ToSQL().

Complex Filters with Expression Combinators

For OR conditions, nested logic, and subqueries — the Expression API composes:

// Active premium users OR users with high spending
q := db.Select().From("users").
    Where(relica.Or(
        relica.And(
            relica.Eq("status", "active"),
            relica.Eq("plan", "premium"),
        ),
        relica.GreaterThan("total_spent", 10000),
    ))

// Generated: WHERE ("status" = $1 AND "plan" = $2) OR ("total_spent" > $3)

This is composable at the Go level — not SQL string templates, not code generation, not struct tags. Plain Go code that produces safe, readable SQL.

Beyond Dynamic Queries: What a Modern Go Query Builder Looks Like

Struct-Based CRUD Without the ORM

user := User{Name: "Alice", Email: "alice@example.com"}
db.Model(&user).Insert()
// user.ID is populated automatically
// PostgreSQL uses RETURNING, MySQL uses LastInsertId — you don't care

original := user
user.Email = "alice.smith@example.com"
db.Model(&user).UpdateChanged(&original)
// Only updates email — detects changed fields via reflect

This is not an ORM. There are no relations, no eager loading, no migrations, no hooks. It's struct scanning and query building — explicit operations that produce predictable SQL.

JOINs with Properly Quoted Table Aliases

db.Select("c.name", "e.name", "e.salary").
    From("companies c").
    LeftJoin("employees e", "e.company_id = c.id").
    Where(relica.Eq("c.status", "active")).
    Where(relica.GreaterThan("e.salary", 80000)).
    All(&results)

Table-aliased columns like c.status are correctly split and quoted for each dialect — "c"."status" for PostgreSQL, `c`.`status` for MySQL. This was a real bug we found and fixed — every identifier in the entire SQL generation pipeline is now properly quoted.

Transactions with Full API Parity

All query methods available on DB are also available on Tx — including batch operations and upserts:

err := db.Transactional(func(tx *relica.Tx) error {
    tx.BatchInsert("orders", []string{"user_id", "total"}).
        Values(1, 99.99).
        Values(2, 149.50).
        Execute()

    return nil  // auto-commit
})
// Panic inside the closure? Auto-rollback + re-panic

Error Classification That Works Across Databases

_, err := db.Model(&user).Insert()

if relica.IsUniqueViolation(err) {
    // Duplicate email — same function on PostgreSQL, MySQL, SQLite
    return ErrEmailTaken
}

if relica.IsForeignKeyViolation(err) {
    // Referenced record doesn't exist
    return ErrInvalidReference
}

No parsing error strings. No database-specific error code checks. One function, three databases.

Production-Grade Engineering

Relica isn't a weekend project. The v0.12.0 release involved a thorough security review that fixed 32 findings across identifier quoting, error handling, API consistency, and correctness:

1700+ tests, ~90% coverage — unit tests with go-sqlmock, integration tests on real PostgreSQL, MySQL, and SQLite via testcontainers
Zero production dependencies — only database/sql from the standard library
Zero panics from public API — every error path returns error, never crashes your process
Zero lint issues — golangci-lint with 10+ analyzers including cyclop, govet, goconst
Listed in awesome-go under SQL Query Builders
API stability commitment — Relica follows "never release v2.0.0" philosophy. After v1.0, your code won't break on updates

Integration tests run on real databases with SQL reserved words as column names (order, select, group) — because if your query builder can't handle WHERE "order" = $1, it's not production-ready.

Getting Started in 30 Seconds

go get github.com/coregx/relica

import (
    "github.com/coregx/relica"
    _ "github.com/lib/pq"  // or mysql, or sqlite
)

db, err := relica.Open("postgres",
    "postgres://user:pass@localhost/mydb?sslmode=disable")
if err != nil {
    log.Fatal(err)
}
defer db.Close()

// Dynamic query — no string concatenation
q := db.Select().From("users")
if status != "" {
    q = q.Where(relica.Eq("status", status))
}

var users []User
err = q.OrderBy("created_at DESC").Limit(20).All(&users)

Works with lib/pq, pgx, go-sql-driver/mysql, modernc.org/sqlite, and any database/sql-compatible driver.

Full docs: pkg.go.dev/github.com/coregx/relica
Migration guides: From GORM | From sqlx

The Go SQL Ecosystem Deserves Better

The fact that dynamic WHERE clauses — the most basic requirement of any API with filters — remain unsolved in Go's most popular SQL libraries is a failure of the ecosystem.

sqlc is great but static. sqlx is abandoned. GORM trades transparency for convenience. squirrel is unmaintained and insecure.

Relica exists because I needed the middle ground: query builder convenience with raw SQL transparency, zero dependencies, and an API that won't change when you upgrade.

If you've been doing WHERE 1=1 — you can stop now.

GitHub: github.com/coregx/relica

How You Can Help

Relica is open source and actively maintained. Here's how to get involved:

Try it — replace one WHERE 1=1 query in your project and see if it clicks
Report bugs — if something doesn't work as expected, open an issue. We respond fast (0 open issues as of this writing)
Send PRs — bug fixes, new dialect support, documentation improvements — all welcome
Star the repo — it helps other developers discover Relica when searching for Go query builders
Tell others — if Relica solved a real problem for you, share it with your team or community
Write about it — blog posts, tutorials, comparisons — the more perspectives, the better the ecosystem

The Go SQL ecosystem has been stuck between "too much magic" and "too much boilerplate" for too long. Let's fix that together.

ThinkPad E14 Gen 7: no sound from speakers or mic on Windows 10? It's the Windows 11-only audio APOs

Andrey Kolkov — Mon, 22 Jun 2026 16:36:59 +0000

TL;DR — On a laptop that ships Windows 11 but was downgraded to Windows 10, the built-in speakers can go completely silent while headphones and USB audio work perfectly. The cause is usually not "the hardware is unsupported." On my ThinkPad E14 Gen 7 the audio driver registers its Dolby APO (Audio Processing Object) COM classes only inside an INF section gated to Windows 11. On Windows 10 that section is skipped, so the audio engine tries to CoCreateInstance an APO that was never registered, fails with REGDB_E_CLASSNOTREG, and the entire speaker stream fails to build — no sound, empty Volume Mixer, "Failed to play test tone." Registering the five missing classes by hand brings the speakers back (clean stereo). Everything below is reproducible with PowerShell, and every claim is backed by an HRESULT or an event-log entry rather than a guess. The same machine's built-in microphone was dead too — a sibling APO bug with the opposite fix; there's a companion section on it near the end.

Tested on


Machine	Lenovo ThinkPad E14 Gen 7 (Intel), machine type 21SX (21SXS0N500)
OS	Windows 10 Pro 22H2 (build 19045)
Audio stack	"Senary Audio" (Conexant/Synaptics CX) codec · Intel Smart Sound Technology (SST) · Dolby DAX3 APO · Elevoc APO
Scope of fix	Speakers output in stereo; built-in mic captures (raw). Dolby on speakers and Elevoc AI noise-suppression on the mic are not reachable on Win10 — see "What I couldn't fix" and the microphone section.

⚠️ Disclaimer. This involves editing HKLM and removing driver packages. It's unofficial and at your own risk. Create a System Restore point first. A full rollback is included at the end. Nothing here touches firmware or hardware.

30-second background: what an APO is

Modern Windows audio runs effects — bass boost, Dolby/DTS, smart-amp speaker protection — as Audio Processing Objects (APOs): COM DLLs the audio engine loads into audiodg.exe and inserts into a per-endpoint processing graph before any audio reaches the device. If the engine can't build that graph for an endpoint, nothing plays on it. Hold onto that: a broken APO doesn't just disable an effect, it can take down the whole endpoint.

The symptom

Speakers: nothing. No sound at all.
Headphones (3.5 mm) and USB audio: perfect.
With Speakers set as the default device, the Volume Mixer shows zero applications — not even System Sounds.
The Windows "Test" tone fails with "Failed to play test tone."
Device Manager looks clean — no yellow bangs; every audio device reports This device is working properly.

That last point is what makes it maddening: by every surface-level check, the audio stack is "fine."

The tempting (and wrong) conclusion

This laptop officially ships Windows 11 only. The obvious story writes itself: "Lenovo doesn't validate Windows 10, the smart-amp driver doesn't exist for it, so the speakers physically can't work. Reinstall Windows 11."

That conclusion is unverified — and it turned out to be wrong. "Officially unsupported" means the vendor doesn't test or ship a Win10 driver; it does not mean the hardware can't make sound. And one clue flatly contradicts the pessimistic story: the endpoint enumerates as Speakers (Senary Audio) in the ACTIVE state, and the driver did install. The path is alive. So let's diagnose instead of guessing.

Everything from here to The fix is read-only. Run PowerShell as your normal user for diagnostics.

Step 1 — Confirm the hardware and driver are healthy

Get-CimInstance Win32_SoundDevice |
  Select-Object Name, Manufacturer, Status, ConfigManagerErrorCode | Format-List

Every device reported Status = OK, ConfigManagerErrorCode = 0 — the Senary codec and the Intel SST OED/BUS components. The services run, too:

Get-CimInstance Win32_Service |
  Where-Object DisplayName -match 'Dolby|Senary|Elevoc' |
  Select-Object Name, State, StartMode
# DolbyDAXAPI         Running  Auto
# SenaryAudioApp.Svc  Running  Auto

So the files are installed and the services are running. The problem is higher up the stack — in stream creation, not the driver binding.

Step 2 — Catch the real failure with a WASAPI probe

If the engine can't build an endpoint's APO graph, it can't even resolve the endpoint's shared mix format: IAudioClient::GetMixFormat and Initialize fail, so no app can open a session — which is exactly why the mixer is empty. Let's confirm that directly (full self-contained probe is in the appendix). On the Speakers endpoint:

Speakers GetMixFormat hr=0x80040154   # REGDB_E_CLASSNOTREG

0x80040154 is REGDB_E_CLASSNOTREG — "class not registered." The engine is trying to CoCreateInstance a COM object in the speaker's effect chain, and it isn't registered. For contrast, IsFormatSupported in exclusive mode returned S_OK on the same endpoint — the hardware happily accepts a real PCM format. The wall is software, in the shared-mode effect graph.

Step 3 — Find which APO classes the endpoint uses

The endpoint's effect chain lives in the registry:

$ep = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\MMDevices\Audio\Render'
# 1) find your Speakers endpoint GUID:
Get-ChildItem $ep | ForEach-Object {
  $n = (Get-ItemProperty "$ep\$($_.PSChildName)\Properties" -EA SilentlyContinue).'{a45c254e-df1c-4efd-8020-67d146a850e0},2'
  [PSCustomObject]@{ GUID = $_.PSChildName; Name = $n }
}
# 2) dump its FxProperties (replace <GUID>):
Get-ItemProperty "$ep\<GUID>\FxProperties" | Format-List

In FxProperties, the property keyed {d04e05a6-594b-4fb6-a80d-01af5eed7d1d} holds the APO CLSIDs the engine instantiates. My speakers endpoint referenced four of the driver's Dolby DAX3 wrapper classes (SFX/EFX/OSFX/OMFX); the driver defines a fifth, MFX, that shows up on other endpoints. I registered all five to be safe:

{0EBD8605-17BB-4AE7-AD76-E86F99A425E9}  (SFX  — stream effect)     <- on speakers
{0EBD8607-17BB-4AE7-AD76-E86F99A425E9}  (EFX  — endpoint effect)   <- on speakers
{0EBD8611-17BB-4AE7-AD76-E86F99A425E9}  (OSFX — offload stream effect) <- on speakers
{0EBD8612-17BB-4AE7-AD76-E86F99A425E9}  (OMFX — offload mode effect)   <- on speakers
{0EBD8606-17BB-4AE7-AD76-E86F99A425E9}  (MFX  — mode effect; driver-defined, registered for completeness)

⚠️ These GUIDs are specific to my driver version. Read your own FxProperties. If the layout differs, treat every CLSID-shaped value there as a candidate and test each one in Step 4 — the culprits are whichever aren't registered.

Step 4 — Confirm those classes are not registered

$apo = '0EBD8605-17BB-4AE7-AD76-E86F99A425E9','0EBD8606-17BB-4AE7-AD76-E86F99A425E9',
       '0EBD8607-17BB-4AE7-AD76-E86F99A425E9','0EBD8611-17BB-4AE7-AD76-E86F99A425E9',
       '0EBD8612-17BB-4AE7-AD76-E86F99A425E9'
foreach ($c in $apo) {
  $v = (Get-ItemProperty "HKLM:\SOFTWARE\Classes\CLSID\{$c}\InprocServer32" -EA SilentlyContinue).'(default)'
  '{0}  {1}' -f $c, ($(if ($v) { "-> $v" } else { '*** NOT REGISTERED ***' }))
}

All five came back NOT REGISTERED — no InprocServer32, so CoCreateInstance can only fail. There's the REGDB_E_CLASSNOTREG. Telling contrast: a different APO on the same endpoint (Elevoc, CLSID 001897D5-…) was registered and pointed at a real DLL. Only the Dolby classes were missing. Why?

Step 5 — The smoking gun in the INF

The Dolby APO DLL is present on disk; Windows just never registered it. Find the driver INF and look at how it registers the classes:

$dir = (Get-ChildItem "$env:SystemRoot\System32\DriverStore\FileRepository\dax3_swc_aposvc.inf_amd64_*" -Directory)[0].FullName
Select-String -Path "$dir\dax3_swc_aposvc.inf" -Pattern 'AddReg|APO_AddReg|InProcServer32|DolbyDax3Apo'

The decisive lines:

AddReg = APO_AddReg_Win11
...
[APO_AddReg_Win11]
HKR,Classes\CLSID\%FX_DolbyAPO_WrapperSFX_CLSID_V2%\InProcServer32,,%REG_EXPAND_SZ%,%13%\DolbyDax3Apo.dll
HKR,Classes\CLSID\%FX_DolbyAPO_WrapperSFX_CLSID_V2%\InProcServer32,ThreadingModel,,"Both"
...

The COM-registration block is literally named APO_AddReg_Win11 and only applies on Windows 11. On Windows 10 it is skipped: the device installs, the services start, the DLL is copied — but the five Dolby APO classes are never registered. The Elevoc APO registered fine because its INF isn't gated to Win11.

Root cause, verified end to end

Layer	State
Codec / SST / services	✅ healthy
Endpoint `Speakers (Senary Audio)`	✅ ACTIVE
Exclusive-mode format support	✅ `S_OK` (hardware is fine)
Shared-mode `GetMixFormat`	❌ `REGDB_E_CLASSNOTREG`
5 Dolby APO CLSIDs in `HKCR\CLSID`	❌ not registered (Win11-only INF section skipped)

The fix

Do what APO_AddReg_Win11 would have done: register the five CLSIDs against the Dolby APO DLL with ThreadingModel = Both.

First, get the real DLL path (the DriverStore folder hash is machine-specific):

(Get-ChildItem "$env:SystemRoot\System32\DriverStore\FileRepository\dax3_swc_aposvc.inf_amd64_*\DolbyDax3Apo.dll")[0].FullName

Option A — registry file

Save as fix-dolby-apo.reg using your own CLSIDs and DLL path (note the doubled backslashes). Write to HKLM\SOFTWARE\Classes, not HKEY_CLASSES_ROOT: APOs load inside audiodg.exe (a system service), so the registration must be machine-wide.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0EBD8605-17BB-4AE7-AD76-E86F99A425E9}\InprocServer32]
@="C:\\Windows\\System32\\DriverStore\\FileRepository\\dax3_swc_aposvc.inf_amd64_2d43ea2009b9f4a0\\DolbyDax3Apo.dll"
"ThreadingModel"="Both"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0EBD8606-17BB-4AE7-AD76-E86F99A425E9}\InprocServer32]
@="C:\\Windows\\System32\\DriverStore\\FileRepository\\dax3_swc_aposvc.inf_amd64_2d43ea2009b9f4a0\\DolbyDax3Apo.dll"
"ThreadingModel"="Both"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0EBD8607-17BB-4AE7-AD76-E86F99A425E9}\InprocServer32]
@="C:\\Windows\\System32\\DriverStore\\FileRepository\\dax3_swc_aposvc.inf_amd64_2d43ea2009b9f4a0\\DolbyDax3Apo.dll"
"ThreadingModel"="Both"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0EBD8611-17BB-4AE7-AD76-E86F99A425E9}\InprocServer32]
@="C:\\Windows\\System32\\DriverStore\\FileRepository\\dax3_swc_aposvc.inf_amd64_2d43ea2009b9f4a0\\DolbyDax3Apo.dll"
"ThreadingModel"="Both"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0EBD8612-17BB-4AE7-AD76-E86F99A425E9}\InprocServer32]
@="C:\\Windows\\System32\\DriverStore\\FileRepository\\dax3_swc_aposvc.inf_amd64_2d43ea2009b9f4a0\\DolbyDax3Apo.dll"
"ThreadingModel"="Both"

Merge it elevated (right-click → Merge → accept UAC), then restart the audio engine from an elevated prompt:

Restart-Service Audiosrv -Force

Option B — PowerShell (auto-detects the DLL path)

#requires -RunAsAdministrator
$dll = (Get-ChildItem "$env:SystemRoot\System32\DriverStore\FileRepository\dax3_swc_aposvc.inf_amd64_*\DolbyDax3Apo.dll")[0].FullName
$apo = '0EBD8605-17BB-4AE7-AD76-E86F99A425E9','0EBD8606-17BB-4AE7-AD76-E86F99A425E9',
       '0EBD8607-17BB-4AE7-AD76-E86F99A425E9','0EBD8611-17BB-4AE7-AD76-E86F99A425E9',
       '0EBD8612-17BB-4AE7-AD76-E86F99A425E9'
foreach ($c in $apo) {
  $k = "HKLM:\SOFTWARE\Classes\CLSID\{$c}\InprocServer32"
  New-Item $k -Force | Out-Null
  New-ItemProperty $k -Name '(default)'       -Value $dll  -PropertyType String -Force | Out-Null
  New-ItemProperty $k -Name 'ThreadingModel'  -Value 'Both' -PropertyType String -Force | Out-Null
}
Restart-Service Audiosrv -Force

Then Settings → System → Sound → set "Speakers (Senary Audio)" as the output device and play something. Still silent? Reboot once — the registration is picked up cleanly on a fresh start.

Verify it worked

Re-run the WASAPI probe; the failure is gone:

Speakers GetMixFormat   = 0x00000000   # S_OK  -> the stream graph builds
Speakers SHARED Initialize = 0x00000000 # the shared stream opens -> apps can play

The Volume Mixer immediately starts listing applications again, and — the real test — the speakers play.

The one setting to leave OFF — and why (with proof)

Keep Speaker Properties → Advanced → Signal Enhancements → "Enable audio enhancements" unchecked. With it off, the speakers play clean stereo. Turn it on and they go silent again until you turn it back off.

I chased why, because "it just doesn't work on Win10" is exactly the hand-wave this post argues against. Comparing the Speakers and Headphones endpoints under …\MMDevices\Audio\Render\{guid}\FxProperties:

Both endpoints reference the same Dolby APO classes (now registered) and the same Elevoc APO.
The headphones endpoint plays fine with enhancements on — so the Dolby APO is not fundamentally incompatible with Windows 10. It runs.
The difference: the speakers endpoint has extra ,100 values binding each Dolby APO instance to the DAX3 APO service device (SWD\DRIVERENUM\{…}#DOLBYAPO_DAX3APOSVC). The headphones endpoint has no such binding.

So enabling enhancements on the speakers activates the service-backed Dolby processing (speaker tuning + smart-amp), and that initialization is what fails. The proof is in the Application event log — the instant enhancements go on, audiodg.exe crashes in a tight loop:

Faulting application name: AUDIODG.EXE
Faulting module name: KERNELBASE.dll
Exception code: 0xe06d7363        # SEH code for an unhandled C++ exception

The engine loads the Dolby APO into audiodg, the APO throws, audiodg dies, Windows restarts it, it reloads the APO, it throws again — hence media apps reporting "can't play audio, restart your PC." The headphones path never loads that service-bound APO, so it never crashes. (Watch it live: Event Viewer → Windows Logs → Application, filter to Application Error, while toggling the checkbox.)

Because the vendor effect chain — which includes smart-amp speaker-protection processing — is bypassed in this configuration, don't run the speakers at maximum volume for extended periods.

What I ruled out (so you don't have to)

Enterprise debugging is as much about eliminating hypotheses as confirming them. Things I tested and discarded, with evidence:

"The APO metadata is missing." The same Win11 INF section also writes APO metadata under AudioEngine\AudioProcessingObjects (Microsoft's APO docs confirm an Apo_AddReg section registers in two places). I replicated it exactly — FriendlyName, Flags=0xc, connection counts, APOInterface0 — for all five wrappers. Enhancements still crashed audiodg. Not the blocker (and the working Elevoc APO has no such metadata at all).
"Wrong / mismatched driver." I'd installed several driver packages while troubleshooting. I verified the bound set is consistent: Intel SST 20.40.12690.2 on every SST device, and DolbyDax3Apo.dll + DAX3API.exe both 3.30811.890.0. There was no version skew and no duplicate Dolby package in the DriverStore.
Stale driver packages. pnputil /enum-drivers revealed three leftover Intel SST packages (including an ancient 10.23.0.3586 from 2020) — all unbound. I removed them with pnputil /delete-driver oemNN.inf (no /force, which refuses if a package is in use). Good hygiene; no effect on the crash. Worth knowing it wasn't the cause.

Net: the crash is an APO-level runtime incompatibility inside a closed-source Dolby DLL, not a registry, metadata, or driver-version gap. Pinning down the exact throw would need a crash dump with Dolby's private symbols, which won't change the outcome.

What I couldn't fix

Full Dolby speaker post-processing is not reachable on Windows 10 here. The service-backed APO crashes audiodg, and that's the genuine boundary the OEM's Windows 11 validation sits behind. The shipped, stable result: working speakers in clean stereo, enhancements off. Honest beats optimistic.

Rollback

Remove the keys and restart audio:

Windows Registry Editor Version 5.00

[-HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0EBD8605-17BB-4AE7-AD76-E86F99A425E9}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0EBD8606-17BB-4AE7-AD76-E86F99A425E9}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0EBD8607-17BB-4AE7-AD76-E86F99A425E9}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0EBD8611-17BB-4AE7-AD76-E86F99A425E9}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0EBD8612-17BB-4AE7-AD76-E86F99A425E9}]

You're never worse off than the original "no sound" state.

Make it work on your machine

The exact GUIDs, DLL, and INF differ per vendor and driver version, but the method generalizes:

Probe the Speakers endpoint with WASAPI. If GetMixFormat returns 0x80040154, you have this class of bug.
Read the endpoint's FxProperties → key {d04e05a6-594b-4fb6-a80d-01af5eed7d1d} for the APO CLSIDs.
Check each under HKLM:\SOFTWARE\Classes\CLSID\{…}\InprocServer32. Missing ones are your culprits.
Find the owning driver in DriverStore\FileRepository and Select-String its INF for an AddReg section that's OS-gated (look for Win11, a build decoration, or an unapplied section). It names the DLL and ThreadingModel to register.
Register the missing CLSIDs against that DLL and Restart-Service Audiosrv.

This pattern shows up on many "Windows 11-only" laptops force-installed with Windows 10, and occasionally after Windows Update swaps an audio driver. Realtek / Conexant / Synaptics codecs paired with Dolby / DTS / Waves / Nahimic APO stacks are all candidates.

Companion case: the microphone — same crash, the opposite fix

After the speakers, the built-in microphone turned out to be dead too — and it's the same audiodg crash wearing a different mask, with a fix that's the mirror image of the speaker one.

Symptom: the internal mic array captures nothing; a 3.5 mm headset mic or a USB mic works fine.

Probe (capture side — EnumAudioEndpoints with dataFlow = eCapture):

Microphone Array  GetMixFormat = 0x00000000      # format resolves fine...
Microphone Array  Initialize   = 0x800706BE      # ...but RPC_S_CALL_FAILED

GetMixFormat succeeding — unlike the speakers' REGDB_E_CLASSNOTREG — means the capture APO classes are registered. The 0x800706BE (RPC_S_CALL_FAILED) on Initialize is the tell: the RPC channel to audiodg dropped mid-call, because audiodg crashed. The Application log confirms the same 0xe06d7363 C++ exception — this time thrown by the Elevoc AI noise-suppression capture APO as it initializes on the mic stream. Same family as the speakers' "enhancements on" crash, opposite registration state.

Why the speaker fix doesn't transfer. The Dolby case was a missing class — you add it. Here the Elevoc class is present and loads, then throws at runtime. Worse, every endpoint-level workaround failed to stick: turning off "audio enhancements", deleting the APO from the endpoint's FxProperties, even stopping the Elevoc service — the driver re-applies the effect chain on every audio restart. And there's no Win10 driver to fall back to: Lenovo ships only Windows 11 audio drivers for this model, Windows Update offers no audio driver, and copying the correct per-codec config into System32\ElevocConfig didn't stop the crash. (Elevoc does build Win10 APOs — they ship on older models — but only as GNA-era builds for those platforms' codecs, with no models for this machine. So the APO isn't inherently Win10-hostile; there just isn't a build that fits this hardware.)

The fix: remove the layer. Since the crash is the Elevoc APO itself and it's driver-enforced, take Elevoc out of the capture path at the driver level so the mic falls back to raw Intel SST capture:

# elevated. Find the oemNN.inf publish names first:
pnputil /enum-drivers     # locate: elevocapo64.inf, elevocapo64ext.inf, intcdmicext_e.inf
# then remove each (this uninstalls from the device and deletes the package):
pnputil /delete-driver oemNN.inf /uninstall /force
Restart-Service Audiosrv -Force      # then reboot to finish

Re-probe:

Microphone Array  GetMixFormat = 0x00000000
Microphone Array  Initialize   = 0x00000000   # stream opens; audiodg stable, 0 crashes

The mic now works — raw, without Elevoc's AI noise-suppression, which is a fair trade for a microphone that exists. Reversible: reinstalling the vendor "Audio Driver" bundle restores Elevoc (and the crash). If you need the AI processing, its only fully-supported home on this hardware is Windows 11.

The symmetry worth remembering: one endpoint failed because a needed APO was missing → register it; the other failed because a present APO was incompatible → remove it. Same audiodg, opposite remedies — and the WASAPI HRESULT told you which was which (REGDB_E_CLASSNOTREG vs a crash-induced RPC_S_CALL_FAILED) before you changed a thing.

Key takeaways

"Officially unsupported" is a support policy, not a law of physics. Verify before you conclude.
A broken APO can silence an entire endpoint — render or capture — not just an effect, because the engine can't build the processing graph.
The HRESULT names the failure mode: REGDB_E_CLASSNOTREG = a needed APO isn't registered (add it); a crash-induced RPC_S_CALL_FAILED with audiodg faulting 0xe06d7363 = a present APO is incompatible and throws (remove it). Opposite diagnoses, opposite fixes.
Register APOs under HKLM\SOFTWARE\Classes\CLSID (machine-wide) — audiodg.exe is a service and won't see per-user HKCU classes.
Endpoint-level edits (FxProperties, "disable enhancements") don't stick if the vendor driver re-applies the effect chain — for those, you act at the driver level (pnputil /delete-driver).
Let the event log and HRESULTs carry the argument. Every step here was a code, not a hunch — including the parts that say "this can't be fixed."

Appendix: the WASAPI probe

Self-contained; run as your normal user. It finds the Speakers endpoint and reports GetMixFormat (and, after the fix, the shared-mode Initialize).

$cs = @'
using System; using System.Runtime.InteropServices;
public static class P {
  [ComImport, Guid("BCDE0395-E52F-467C-8E3D-C4579291692E")] class E {}
  [Guid("A95664D2-9614-4F35-A746-DE8DB63617E6"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
  interface IE { [PreserveSig] int EnumAudioEndpoints(int f,int m,out IC c); [PreserveSig] int GetDefaultAudioEndpoint(int f,int r,out ID d); }
  [Guid("0BD7A1BE-7A1A-44DB-8397-CC5392387B5E"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
  interface IC { [PreserveSig] int GetCount(out int c); [PreserveSig] int Item(int i,out ID d); }
  [Guid("D666063F-1587-4E43-81F1-B948E807363F"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
  interface ID { [PreserveSig] int Activate(ref Guid i,int x,IntPtr p,[MarshalAs(UnmanagedType.IUnknown)] out object o);
    [PreserveSig] int OpenPropertyStore(int a,out IP ps); [PreserveSig] int GetId([MarshalAs(UnmanagedType.LPWStr)] out string s); [PreserveSig] int GetState(out int s); }
  [Guid("886d8eeb-8cf2-4446-8d02-cdba1dbdcf99"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
  interface IP { [PreserveSig] int GetCount(out int c); [PreserveSig] int GetAt(int i,out PK k); [PreserveSig] int GetValue(ref PK k,out PV v); }
  [StructLayout(LayoutKind.Sequential)] struct PK { public Guid f; public int pid; }
  [StructLayout(LayoutKind.Explicit)] struct PV { [FieldOffset(0)] public short vt; [FieldOffset(8)] public IntPtr p; }
  [Guid("1CB9AD4C-DBFA-4c32-B178-C2F568A703B2"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
  interface IAC { [PreserveSig] int Initialize(int s,int f,long d,long p,IntPtr fmt,IntPtr g); [PreserveSig] int GetBufferSize(out uint n);
    [PreserveSig] int GetStreamLatency(out long l); [PreserveSig] int GetCurrentPadding(out uint n);
    [PreserveSig] int IsFormatSupported(int s,IntPtr f,out IntPtr c); [PreserveSig] int GetMixFormat(out IntPtr f); }
  static string Nm(ID d){ IP ps; if(d.OpenPropertyStore(0,out ps)!=0)return "?";
    var k=new PK{f=new Guid("a45c254e-df1c-4efd-8020-67d146a850e0"),pid=14}; PV v;
    if(ps.GetValue(ref k,out v)!=0||v.p==IntPtr.Zero)return "?"; return Marshal.PtrToStringUni(v.p); }
  public static string Run(){ var en=(IE)(new E()); IC col; en.EnumAudioEndpoints(0,1,out col); int n; col.GetCount(out n);
    for(int i=0;i<n;i++){ ID d; col.Item(i,out d); var nm=Nm(d); if(nm!=null&&nm.StartsWith("Speakers")){
      var iid=new Guid("1CB9AD4C-DBFA-4c32-B178-C2F568A703B2"); object o; d.Activate(ref iid,1,IntPtr.Zero,out o);
      var c=(IAC)o; IntPtr f; int hr=c.GetMixFormat(out f); int sh=-1; if(hr==0) sh=c.Initialize(0,0,10000000,0,f,IntPtr.Zero);
      return "Speakers GetMixFormat=0x"+hr.ToString("X8")+"  SHARED Initialize=0x"+sh.ToString("X8"); } }
    return "No active Speakers endpoint found"; }
}
'@
Add-Type -TypeDefinition $cs -Language CSharp
[P]::Run()

To probe the microphone instead, change EnumAudioEndpoints(0, …) to EnumAudioEndpoints(1, …) (eCapture) and match "Microphone" instead of "Speakers".

Found this useful, or hit a variant on a different machine? Drop your codec + APO stack and the GetMixFormat HRESULT in the comments — the method in "Make it work on your machine" should map across vendors.

gogpu/compose: Multi-Process GUI Composition in Pure Go

Andrey Kolkov — Sun, 17 May 2026 10:07:38 +0000

A Raspberry Pi displays a smart mirror. Clock in the top corner. Weather below. Notifications slide in from the bottom. Each panel is a separate process — if weather crashes, the clock keeps ticking.

This is gogpu/compose: a Pure Go library that lets independent processes render UI into offscreen buffers and ship pixels to a single compositor over Unix sockets.

go get github.com/gogpu/compose

The Problem

Desktop applications are monolithic. One process, one crash domain. A bug in the notification panel takes down the entire display.

Wayland solved this at the OS level — every application is a separate client, and the compositor (KWin, Mutter, Sway) combines their surfaces. Android SurfaceFlinger does the same thing for mobile apps.

But what if you need this pattern inside your application? A dashboard where each data source is an independent process. A kiosk where third-party modules render into slots. A plugin host where untrusted code runs in its own crash domain.

There was no Go library for this. You had to roll your own socket protocol, frame encoding, connection management, flow control. Every project reinvented the same plumbing.

What We Built

compose is a two-sided library: a Server (compositor) accepts connections, a Client (module) publishes frames. One import, one socket path.

Module side

client, _ := compose.Dial("/tmp/compose.sock",
    compose.WithName("clock"),
    compose.WithFrameSize(400, 120),
    compose.WithFPS(1),
)
defer client.Close()

client.OnFrameRequest(func() {
    dc := gg.NewContext(400, 120)
    dc.SetRGB(1, 1, 1)
    dc.DrawString(time.Now().Format("15:04:05"), 20, 60)

    client.PublishFrame(compose.Frame{
        Pixels: dc.ImageRGBA().Pix,
        Width:  400,
        Height: 120,
    })
})

Compositor side

srv, _ := compose.Listen("/tmp/compose.sock",
    compose.WithMaxModules(8),
    compose.WithCompression("lz4"),
)

srv.OnFrame(func(f compose.Frame) {
    layout.Place(f.Name, f.Pixels)
})

srv.OnConnect(func(id uint64, name string) {
    log.Printf("module connected: %s", name)
})

srv.OnDisconnect(func(id uint64, name string) {
    log.Printf("module gone: %s", name)
})

That's it. The module renders into a pixel buffer, publishes it. The compositor receives frames, positions them on screen. Hot-plug is automatic — modules come and go without restarting the compositor.

The Wire Protocol

Every frame travels as a 64-byte header followed by pixel data.

┌──────────────────────────────────────────────────────────┐
│ Magic "COMP" │ Version │ MsgType │ Flags                 │
│ ModuleID     │ Sequence              │ Timestamp         │
│ Width │ Height │ Stride  │ DirtyRect (x,y,w,h)           │
│ PixelFormat │ Compression │ PayloadSize │ Uncompressed   │
└──────────────────────────────────────────────────────────┘
64 bytes, little-endian, cache-line aligned

The header is fixed-size — one io.ReadFull call parses it. No variable-length fields, no schema negotiation mid-stream. Encode and decode take under 10 ns and under 25 ns respectively, with zero allocations.

The protocol carries dirty rectangles (only the changed region's pixels), compression flags, and monotonic sequence numbers for frame ordering.

Handshake

When a module connects, it sends a 128-byte HelloMsg (name, dimensions, preferred FPS). The compositor replies with a 128-byte WelcomeMsg (assigned module ID, granted transport). Fixed-size messages — no JSON parsing, no protobuf dependency, no allocation.

LZ4 Compression

GUI pixels compress exceptionally well. Buttons, backgrounds, text labels — large flat-color regions that LZ4 handles at near-memcpy speed.

Frame Size	Encode	Decode	Ratio
400×120 (small module)	2,753 MB/s	1,175 MB/s	99.6% savings
1920×1080 (full HD)	2,728 MB/s	1,446 MB/s	varies

A 192 KB module frame compresses to ~810 bytes. At 60 FPS, that's 47 KB/s over the socket — trivial for any transport.

Compression is optional. Static modules (clock, weather) benefit most. Animated modules with random pixel patterns can disable it with a flag in the frame header.

Frame Delivery: Push, Pull, and Mailbox

We researched how 9 production compositors handle frame delivery — Wayland, Android SurfaceFlinger, Chromium viz, Flutter, PipeWire, Windows DWM, macOS Core Animation, Vulkan, and X11. They all converge on the same pattern: producers submit whenever ready, the compositor samples the latest frame at its own cadence. "Push vs pull" is a false dichotomy.

compose supports both, with no mode negotiation:

Push — module sends frames whenever data changes:

// Stock ticker: push on every price update
for price := range ticker {
    client.PublishFrame(renderPrice(price))
}

Pull — module renders only when the compositor asks:

// Clock: render on demand (Wayland frame callback pattern)
client.OnFrameRequest(func() {
    client.PublishFrame(renderClock())
})

Mailbox — the compositor samples latest frames on each render tick:

// Compositor render loop: always gets the latest frame from each module
frames := srv.Snapshot()
for id, frame := range frames {
    compositor.Blit(id, frame)
}

Each module has a mailbox slot. When a module pushes faster than the compositor renders, intermediate frames are silently overwritten — latest always wins. This is the same pattern as Android's acquireLatestBuffer() and Vulkan's VK_PRESENT_MODE_MAILBOX_KHR. No stale frame accumulation, no FIFO backlog.

The adaptive flow controller still works for pull-mode modules: after 3 consecutive missed responses, it halves the request rate. Push modules bypass it entirely — the mailbox handles everything.

Architecture: Enterprise internal/

The public API has fewer than 15 exported declarations — 5 types, 2 constructors, 5 option functions, and a handful of sentinel errors. Everything else is hidden behind internal/ packages:

compose/                        # Public: Listen, Dial, Frame, options
├── internal/protocol/          # Wire format (100% coverage)
├── internal/codec/             # Raw + LZ4 (97% coverage)
├── internal/conn/              # Module lifecycle (98.9% coverage)
├── internal/flow/              # Pull-based pacing (100% coverage)
└── internal/transport/socket/  # Unix sockets (95.1% coverage)

The dependency graph is a clean DAG — protocol is the leaf (imported by all, imports nothing), codec/conn/flow are independent, transport/socket imports only protocol. No cycles possible by construction.

This isn't an accident. We designed compose the way database/sql is designed: public Server/Client wrap internal implementations. Users never import sub-packages. Adding a shared memory transport (Phase 2) won't change the public API — it's a new internal/transport/shm/ behind an existing WithSharedMemory() option.

By the Numbers

Metric	Value
Source code	2,960 LOC
Test code	6,066 LOC
Total	9,026 LOC
Test cases	179
Packages	6
Files	38
Coverage (internal avg)	98%
Header encode	< 10 ns, 0 allocs
Header decode	< 25 ns, 0 allocs
LZ4 encode throughput	2.7+ GB/s
Socket throughput	5.9+ GB/s
Dependencies	1 (`pierrec/lz4/v4`)
CGO	Zero
CI	Ubuntu + macOS + Windows
Lint (30+ rules)	0 issues

2× more test code than source code. Every internal package is independently testable with its own benchmark suite.

Who Needs This

Smart mirrors and kiosks. Independent modules (time, weather, transit, notifications) render into slots. A crash in one module doesn't affect the display.

Modular dashboards. Each data source is its own process, possibly developed by different teams. The compositor arranges them on screen.

Plugin hosts. Third-party plugins run in separate processes. The host application composites their output without trusting their code. f4 by @unxed — a full Go reimplementation of Far Manager — already uses --gui=gogpu for GPU-accelerated rendering and has an out-of-process plugin architecture (MessagePack RPC supporting Go, Python, Rust, Node.js, C++, Lua). compose could serve as the pixel transport between f4's plugin host and its GUI modules.

Cross-language UIs. The wire protocol is language-agnostic. A Rust module or a Python script can participate — anything that writes RGBA to a Unix socket.

KiGo by @AgentNemo00 — a modular Go application — is already using offscreen rendering with multi-process composition. His feedback on v0.1.0 directly shaped the mailbox delivery model in v0.2.0: he told us he uses push, we researched 9 compositors, and shipped Snapshot() two days later.

These aren't hypothetical users waiting for a stable release. They're building real software on the GoGPU stack right now — and finding real bugs that make the ecosystem better. Every project that adopts GoGPU accelerates the path to enterprise grade. If you have a desktop app, a dashboard, a kiosk, a file manager, an IDE panel — there's never been a better time to try it in Pure Go.

What's Next

Phase 2: Reference examples. Three separate binaries — compositor, clock module, notification module — demonstrating the full multi-process workflow.

Phase 3: Shared memory transport. Triple-buffer ring in mmap'd memory with atomic slot states. Zero-copy pixel transfer for 60 FPS at 1080p. The public API stays the same — you just pass WithSharedMemory().

Phase 4: Delta frames. Send only the dirty rectangle's pixels, not the full frame. The protocol already carries dirty rects in the header — we just need the compositor-side texture cache.

Try It

go get github.com/gogpu/compose

GitHub: github.com/gogpu/compose
Architecture: docs/ARCHITECTURE.md
GoDoc: pkg.go.dev/github.com/gogpu/compose
Discussion: RFC #177

Part of the GoGPU Ecosystem

compose is the newest member of GoGPU — 800K+ lines of Pure Go GPU computing:

Library	Purpose
wgpu	Pure Go WebGPU (Vulkan/Metal/DX12/GLES)
naga	Shader compiler (WGSL → SPIR-V/MSL/GLSL/HLSL/DXIL)
gg	2D graphics with GPU acceleration
ui	Enterprise GUI toolkit (22+ widgets, 4 themes)
gogpu	Application framework, windowing
compose	Multi-process composition (this library)
systray	System tray (Win32/macOS/Linux)
audio	Pure Go audio engine

Help Us Get to Enterprise Grade

The ecosystem grows faster with every pair of eyes on it. Here's how you can help:

Test it. Run go get github.com/gogpu/compose, build a two-process prototype, tell us what breaks. Edge cases on your OS, your hardware, your use case — that's what we can't find ourselves.
Validate the API. Does Listen/Dial/PublishFrame feel right? Is the wire protocol missing a field you need? The API is still v0.x — now is the time to reshape it, before it freezes.
Propose and discuss. Open an issue or join the compose RFC discussion. Real use cases drive the roadmap — not hypotheticals.
Spread the word. Star the repo, share this article, mention it in your Go meetup. The more developers use the ecosystem, the faster it reaches enterprise grade.
Contribute. Every PR matters — from typo fixes to new transport implementations. See CONTRIBUTING.md.

The entire GoGPU ecosystem — 800K+ lines of Pure Go — is built by a small team. But the libraries are production-ready enough that people are building real products on them: a Far Manager rewrite with GPU rendering, an ML framework fully migrated to our WebGPU stack, a Quake 1 engine port running on gogpu/wgpu Vulkan (demo), modular app platforms. The more developers who start building on GoGPU — whether it's a new project or porting an existing one — the faster the entire ecosystem matures. Your project's edge cases become our test suite. Your feature requests become our roadmap.

Start building. We'll make sure the foundation holds.

Building what Go "can't do." One library at a time.

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.

DEV Community: Andrey Kolkov

gogpu/ui v0.1.54: We Built Flutter's Gesture System in Pure Go — Arena, Recognizers, and All

The Problem: Every Widget Reinvented Click Detection

What We Built

The Gesture Arena

Four Recognizers + VelocityTracker

Per-Device Thresholds

Unified Pointer Pipeline

Container Widget Hit-Testing

TextField: The Full Story

OS Clipboard

Signals Integration

Numbers

What's Next

Help Us Build Go's GUI Future

Google Says Go Is Ideal for AI-Assisted Engineering. We've Been Proving It for a Year.

What Google Got Right

"The bottleneck shifted from writing to reviewing"

"Go's integrated platform enables AI self-correction loops"

"Static types = safety net for agentic code"

"Single static binary, zero system dependencies"

What Google Didn't Do — and We Did

What We Learned That Google Didn't Mention

AI-generated code needs claim-by-claim validation, not just compilation

Enterprise references prevent AI from reinventing wheels badly

Multi-agent architecture, not one AI editing everything

CI lint versions drift — and AI can't predict it

The Numbers

The Ecosystem

GoGPU: Extracting a GPU Compositor in Pure Go — Patterns from Flutter and Chromium

The Setup: a Compositor Hidden Inside a Drawing Library

The Breaking Point: Three Problems, One Root Cause

Problem 1: Damage rects were single-source

Problem 2: Two overlays, two libraries

Problem 3: The move that broke everything

Phase 1: Moving the Compositor Out of gg (ADR-067)

Phase 2: Extracting internal/compositor/ (ADR-069)

Research first

What we actually built

The numbers

Rules That Emerged

What We Learned

The Ecosystem

Try It, Break It, Tell Us

Support the Project

We Built a Pure Go 3D Renderer — Then Embedded It Inside a GUI Widget

The 20-Line Rotating Cube

The Real Challenge: 3D + UI

Pattern 1: Fullscreen 3D + 2D Overlay

The Result

Pattern 2: 3D Inside a GUI Widget

Eight Issues Across Five Repos

Bug 1: MSAA Resolve Overwrites External Content

Bug 2: GPU Buffer Use-After-Free

Bug 3: Layer Tree Missing External Texture Node

Shared Command Encoder: The Third Way

The Architecture

The Ecosystem Is Accelerating

By the Numbers

Try It

What's Next

How You Can Help

Links

Go's sql.Null[T] Will Never Get JSON Support. Here's What We Built Instead.

The Three Bad Options (Before opt)

1. sql.Null[T] — SQL works, JSON broken

2. *string — JSON works, everything else is awkward

3. guregu/null — Works, but carries 10 years of legacy

opt: Option<T> for Go

What Makes opt Different

1. Three-State Field[T] — The PATCH API Killer Feature

2. OrNull Constructors — No More Boilerplate

3. Functional API — Map, FlatMap, Equal

4. Generic Option[T] That Actually Works

5. zero/ Subpackage — Alternative Semantics

Comparison

Performance

Why New Projects Should Start with opt

Getting Started

Help Us Get to v1.0.0

1. `sql.Null[T]` — SQL works, JSON broken

2. `*string` — JSON works, everything else is awkward

3. `guregu/null` — Works, but carries 10 years of legacy

1. Three-State `Field[T]` — The PATCH API Killer Feature

2. `OrNull` Constructors — No More Boilerplate

4. Generic `Option[T]` That Actually Works

5. `zero/` Subpackage — Alternative Semantics