Responsiveness / rendering, memory, and work distribution.
PaintFE tries to avoid doing full-document work for a small edit. Changed regions, tiled image storage, native CPU parallelism, and supported GPU paths each help in different parts of the editor. Actual performance still depends on the document, operation, hardware, and platform.
Keep small edits local.
Brush and preview work track the part of the canvas that changed. The document uses tiled image storage, so an edit can work with the affected chunks rather than treating the entire canvas as one flat image.
- Changed regions drive preview and texture-update work where the path supports it.
- Brush falloff uses cached lookup data while the relevant brush settings are unchanged.
- The display path reuses buffers and textures where practical instead of allocating for every interaction.
Use the available work path.
Some compositing, filters, and transforms can spread work across native CPU cores. Supported operations can also use wgpu-backed rendering or compute paths. PaintFE falls back to a suitable CPU path when a GPU path is unavailable.
Store the least expensive useful history.
PaintFE uses different undo representations for different edits. A brush stroke can retain changed pixels, while operations that affect a layer or document use a more appropriate snapshot. Tile data is shared until a modified tile needs its own backing image.
This is a trade-off, not a promise of free memory: large documents, deep history, animated content, and some effects can still use substantial resources.
Read the implementation.
The source is the authoritative detail for backend support, fallbacks, and the operations that use a GPU path. These links are a better home for deeper engineering discussion than a marketing-style diagram.