[Software Renderer/Windows] Severe Rendering Bugs, Freezes, and Performance Regressions

[ChristianG1984]

[Software Renderer/Windows] Severe Rendering Bugs, Freezes, and Performance Regressions

Note: This issue was analyzed and compiled by an AI coding agent assisting a human developer. We performed a deep dive into the software renderer fallback path and identified several critical issues affecting gogpu and wgpu.

Environment

• OS: Microsoft Windows 10 Pro (10.0.19045)
• Hardware GPU: Intel(R) HD Graphics 4600 (Integrated GPU)
• Go Version: 1.26.4
• Framework Versions:
  • github.com/gogpu/ui v0.1.40
  • github.com/gogpu/gg v0.49.5
  • github.com/gogpu/gogpu v0.43.0
  • github.com/gogpu/wgpu v0.30.7

Description

When running gogpu/ui applications (like the hello or gallery examples) on Windows without hardware acceleration (falling back to the Software Renderer), the application exhibits severe bugs ranging from complete freezes to corrupted visuals and overlapping layouts.

While the framework's development has done a fantastic job implementing modern GPU features (MSAA, Compositor Clipping) for hardware backends, these features heavily penalize the pure-Go CPU fallback. Additionally, several core WebGPU features are simply stubbed out or implemented incorrectly in the hal/software backend.

Here is a detailed breakdown of the 6 root causes we identified during our debugging session:

---

1. Massive Performance Regression / "Freeze" (ADR-021 & MSAA)

Symptom: The application appears to completely freeze immediately upon startup.
Root Cause: A goroutine dump reveals the application isn't deadlocked; it is spinning at 100% CPU in hal/software/raster.Rasterize executing SPIR-V fragment shaders.
In gg v0.49.5, ADR-021 enforces full-screen renders (encodeSubmitSurfaceGrouped) and ignores DamageRects when MSAA or grouped rendering is active. For a pure CPU software renderer, calculating complex SDF shaders for an entire 800x900 window (potentially at 4x MSAA) every frame creates an insurmountable fill-rate bottleneck. It takes minutes per frame, masquerading as a hard freeze.
Proposed Fix: The engine should detect the Software adapter and explicitly disable MSAA and full-screen grouped rendering to force the blitOnly path with strict DamageRects.

2. Missing OS Paint Event Propagation (WM_PAINT)

Symptom: Even when rendering is fast enough, the window often remains completely black until a pointer event (mouse move/click) forces a wake-up.
Root Cause: gogpu v0.43.0 defaults to event-driven rendering (WithContinuousRender(false)). The Windows message loop in internal/platform/platform_windows.go intercepts WM_PAINT and validates the region, but never queues a redraw event. WaitEvents() remains blocked.
Proposed Fix: Introduce an EventPaint to the platform interface and trigger app.RequestRedraw() when handling WM_PAINT.

3. Missing DrawIndexed Support

Symptom: Text rendering is either completely missing or severely corrupted.
Root Cause: Modern text pipelines (like MSDF) use indexed quads. However, DrawIndexed in hal/software/command.go is an empty no-op. All text draw calls are silently dropped.
Proposed Fix: Implement executeDrawIndexed and index-aware vertex fetchers (fetchTrianglesWithIndices) to properly resolve attributes.

4. Ignored Dynamic Uniform Buffer Offsets

Symptom: Elements within lists (e.g., 1000 ListView items) fail to layout correctly and instead stack on top of each other at (0,0).
Root Cause: The software backend's SetBindGroup ignores dynamicOffsets. The rasterizer always reads uniform data starting at offset 0.
Proposed Fix: Update bufferBinding to retain base offsets, and add dynamicOffsets logic inside buildExecutionContext to slice the buffer correctly before executing the shader.

5. Red/Blue (R/B) Channel Swap on Existing Pixels

Symptom: Backgrounds and borders turn orange instead of blue; colors degrade continuously on every redraw.
Root Cause: Windows offscreen DIBs use BGRA8Unorm. When draw.go reads existing pixels for alpha blending, it blindly assumes RGBA. The R and B channels are swapped when reading, and swapped again when writing, permanently corrupting the existing background pixels.
Proposed Fix: Check if the target format is BGRA and apply the correct swizzle when feeding existingData into pipe.SetPixel.

6. Missing GDI Synchronization

Symptom: Random black blocks or tearing during partial blits.
Root Cause: blitDamageRectsToWindow uses BitBlt directly after CPU writes to the DIB section. Without calling GdiFlush(), GDI commands and CPU memory writes race, resulting in stale data being presented.
Proposed Fix: Call GdiFlush() before and after GDI blit calls in blit_windows.go.

[kolkov]

@ChristianG1984 thanks for the thorough report — we went through each of the 6 points and validated them against the current code.

Here's what we found:

#1 (MSAA on software backend) — confirmed. The software backend doesn't reject SampleCount=4, so resolveSampleCount() succeeds and every frame pays for an unnecessary MSAA texture + copy. One note: the software rasterizer uses triangle rasterization, not per-pixel SDF shader interpretation, so the actual mechanism differs from what you described — but the wasted work is real.

#2 (WM_PAINT) — confirmed. The WM_PAINT handler calls DefWindowProc to validate the region but never queues an event. X11 has this wired up (EventExpose → RequestRedraw()), Windows doesn't. With event-driven rendering (v0.43.0 default) this means the window stays black until a mouse or keyboard event arrives.

#3 (DrawIndexed) — this was a real bug historically, but it's already been fixed. DrawIndexed in hal/software/command.go now has a full implementation with index buffer resolution, Uint16/Uint32 support, and baseVertex. Both text pipelines work on the software backend.

#4 (dynamic offsets) — confirmed as a spec violation. Both SetBindGroup methods discard the dynamicOffsets parameter, and CreateBindGroup drops BufferBinding.Offset/Size. Currently the ecosystem doesn't use dynamic offsets (all call sites pass nil), so there's no visible effect yet — but it will break anyone sub-allocating from a larger uniform buffer.

#5 (BGRA swap) — partially confirmed. The fullscreen blit and write-back paths handle BGRA correctly. The bug is in the alpha blending compositing path — when loading existing framebuffer pixels for blending (draw.go:274,1012), raw BGRA bytes are read as RGBA without swizzle. Opaque overwrites work fine (double-swap cancels), but semi-transparent blending produces wrong colors.

#6 (GdiFlush) — the call is indeed missing. Our prior ADR dismissed it in the context of the old StretchDIBits approach, but the current CreateDIBSection+BitBlt path is different (Qt6 calls GdiFlush here, SDL3 does not). No artifacts observed in practice, but we'll add it defensively.

None of these are actually in ui — the fixes go into wgpu (hal/software/) and gogpu (platform layer). We'll create issues in the right repos and link them here. #1 and #2 are the highest priority since they cause the "freeze" and "black window" you're seeing.

[kolkov]

Created targeted issues in the correct repos:

#	Issue	Priority	Repo
1	gogpu/gogpu#354 — WM_PAINT → EventExpose	high	gogpu
2	gogpu/wgpu#234 — Reject MSAA on software backend	high	wgpu
5	gogpu/wgpu#235 — BGRA swizzle in alpha blending	medium	wgpu
4	gogpu/wgpu#236 — Dynamic uniform buffer offsets	medium	wgpu

#3 (DrawIndexed) is already fixed in the current code. #6 (GdiFlush) is low risk — we'll add it defensively alongside the other software backend fixes.

[kolkov]

All four fixes shipped — wgpu v0.30.8 (MSAA rejection, BGRA blending, dynamic offsets) and gogpu v0.43.3 (WM_PAINT → EventExpose + wgpu cascade).

go get github.com/gogpu/gogpu@v0.43.3
go get github.com/gogpu/wgpu@v0.30.8

Separately, go-webgpu/goffi#59 is landing a fix for goroutine stack moves during FFI callbacks — return values could be silently lost if the stack grew mid-call. That one may also help stability on the software backend.

Let us know how it goes on your Intel HD 4600.

[ChristianG1984]

Note: As with the original report, this follow-up analysis was conducted with the assistance of my AI coding agent. We investigated the process state together to provide this detailed feedback.

Thank you for the fast response and the fixes!

I updated to gogpu v0.43.3 and wgpu v0.30.8 and recompiled. Unfortunately, the exact same freeze still occurs on my Intel HD 4600.
The application opens a completely white window and hangs indefinitely at high CPU usage until I kill the process manually. The behavior is indistinguishable from yesterday.

To figure out why it is still freezing, my AI assistant briefly injected a pprof endpoint into the new build and captured a goroutine dump of the frozen process. It shows that even with your new fixes (and MSAA rejected), the pure-CPU rasterizer is completely stuck rendering the new compositor boundaries.

Here is the relevant part of the trace where the rendering thread spends all its time:

github.com/gogpu/wgpu/hal/software/raster.Rasterize
github.com/gogpu/wgpu/hal/software/raster.(*Pipeline).DrawTrianglesWithFragmentShader
github.com/gogpu/wgpu/hal/software.(*RenderPassEncoder).executeVertexDraw
github.com/gogpu/wgpu/hal/software.(*RenderPassEncoder).executeDraw
github.com/gogpu/wgpu/hal/software.(*RenderPassEncoder).Draw
...
github.com/gogpu/gg/internal/gpu.(*GPURenderSession).RenderFrameGrouped
github.com/gogpu/ui/desktop.(*renderLoop).flushBoundaryToTexture
github.com/gogpu/ui/desktop.(*renderLoop).renderSingleBoundaryFromLayer

It seems the new compositor architecture and off-screen boundary textures in ui v0.1.40 completely overwhelm the software fallback mathematically. Is there any way to bypass this heavy compositor for the software backend, or provide a fast-path?

[kolkov]

@ChristianG1984 since your July 2 test, significant software backend work has shipped:

• gg v0.50.5 (Jul 12): SurfacePixelWriter zero-copy presentation — root surface blit bypasses the SPIR-V render pass entirely (PresentPixels: single memcpy+swizzle into DIB section). Also strategyRasterAtlas mode that skips GPU shape pipelines (SDF/stencil/convex) on software adapters.
• gg v0.50.6 (Jul 15): Fixed 5 latent bugs in software backend GPU texture compositing (the DrawGPUTexture overlay path your trace hits).
• wgpu v0.30.15 (Jul 12): Surface.PresentPixels API + WriteTexture to SurfaceTexture fix.

Could you try updating to the latest?

go get github.com/gogpu/gg@v0.50.11
go get github.com/gogpu/wgpu@v0.30.34
go get github.com/gogpu/gogpu@v0.48.4

Being transparent: the per-boundary offscreen render (flushBoundaryToTexture in your trace) still goes through the software HAL, so complex UIs with many RepaintBoundaries will remain slower than GPU. The root surface final present is now zero-copy, which should help, but the boundary rendering bottleneck needs deeper work.

Our ROADMAP documents the 4-tier optimization plan. Tier 1 (gg direct CPU rasterization — bypassing SPIR-V for shapes/text) is the highest-impact next step.