Summary
GPUI currently has no public path for replacing the pixels of a same-sized image while retaining its atlas allocation. Dynamic pixel surfaces therefore need to remove/reinsert the image or rebuild scene state. They also cannot request nearest-neighbor sampling explicitly.
This blocks efficient terminal framebuffers, pixel canvases, emulators, plots, and video-like surfaces that update a stable image identity every frame.
Proposed capabilities
- construct a
RenderImage from tightly packed BGRA bytes;
- update an existing same-sized
PlatformAtlas tile in place;
- implement that update for Metal, WGPU, and DirectX;
- request nearest-neighbor image sampling;
- present a cached scene after an external atlas resource changes, without rebuilding views, layout, prepaint, or paint.
The default PlatformAtlas::update can retain remove/reinsert semantics for implementations that do not provide a true in-place upload.
Reference implementation
No PR is being opened, per the external-contributor policy.
The branch uses an existing packed sprite field to prove nearest sampling across the three shaders. That is intentionally a reference implementation; an explicit sampler/filter field would be a cleaner public design.
Validation
- New
RenderImage::from_bgra GPUI regression passes.
- Changed Rust files pass Rust 2024 formatting.
- The complete GPUix native suite passes with these GPUI commits: 227 tests.
- Metal was exercised in a real fullscreen dynamic surface at approximately 59 staged frames per second with stable tile reuse.
- WGPU and DirectX implementations and shaders are included, but have not yet been exercised on Linux/Windows hardware and should be covered by CI before adoption.
Would these primitives fit GPUI's image API, or would a dedicated dynamic-texture/canvas abstraction be preferred?
Summary
GPUI currently has no public path for replacing the pixels of a same-sized image while retaining its atlas allocation. Dynamic pixel surfaces therefore need to remove/reinsert the image or rebuild scene state. They also cannot request nearest-neighbor sampling explicitly.
This blocks efficient terminal framebuffers, pixel canvases, emulators, plots, and video-like surfaces that update a stable image identity every frame.
Proposed capabilities
RenderImagefrom tightly packed BGRA bytes;PlatformAtlastile in place;The default
PlatformAtlas::updatecan retain remove/reinsert semantics for implementations that do not provide a true in-place upload.Reference implementation
No PR is being opened, per the external-contributor policy.
The branch uses an existing packed sprite field to prove nearest sampling across the three shaders. That is intentionally a reference implementation; an explicit sampler/filter field would be a cleaner public design.
Validation
RenderImage::from_bgraGPUI regression passes.Would these primitives fit GPUI's image API, or would a dedicated dynamic-texture/canvas abstraction be preferred?