GPU texture atlas pipeline for Skia painting on GTK/WPE
Source/WebCore/platform/graphics/skia/SkiaGPUAtlas.cpp
The Skia painting engine on GTK/WPE uses a record/replay model: drawing commands are first recorded into a picture, then replayed on worker threads using GPU acceleration. This commit introduces a batching optimization where raster (CPU-side) images encountered during recording are packed into a single GPU texture atlas, uploaded once, and then used as atlas sub-regions during replay — avoiding per-image GPU uploads.
The pipeline has three stages. During recording, collectRasterImage() packs images into atlas layouts. After recording, createAtlas() uploads pixel data to a GPU texture — either via DMA-buf (memory-mapping a GBM buffer for direct CPU writes, dispatched to a worker thread) or via GL fallback (updateContents(), synchronous on main thread). During replay, SkiaReplayCanvas virtual overrides (onDrawImage2, onDrawImageRect2) intercept raster image draws and redirect them to atlas texture draws with coordinate remapping. Synchronization between the upload worker and replay workers is handled via AtlasUploadCondition, a custom countdown latch built on Lock and Condition.
Recording (main) Upload (main or worker) Replay workers
│ │ │
├─ collectRasterImage() ──────►│ │
├─ finalize() → AtlasLayouts │ │
├─ createAtlas() ─────────────►│ │
│ DMA-buf: mmap GPU buf ├─ addPending()/signal() ──►│
│ GL: updateContents() │ │
│ ├─ GL fence inserted ───────►│
│ │ ├─ wait() [latch]
│ complete ├─ onDrawImage2()
│ │ └─ atlas draw
│ │ (remapped coords)
Significance
This is a substantial new rendering pipeline — GPU texture batching, cross-thread synchronization, DMA-buf memory-mapped writes, and atlas coordinate substitution — all interacting under concurrent workers, making it historically fertile ground for race conditions and lifetime bugs.