On a machine with Iris Xe and a discrete GPU the default request can pick
the discrete one, so the probe would not test the affected adapter.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
wgpu-hal 30 creates Iris Xe textures as committed resources (its
gfx-rs/wgpu#3552 workaround) with D3D12_HEAP_FLAG_CREATE_NOT_ZEROED, and
egui-wgpu fills each new texture with a single copy. On this driver the
copy leaves 4x4 blocks of all-zero texels showing stale memory, so the
empty corners of Brush Preset picker strokes and tool icons show freed
textures' pixels (often red).
ui-egui's new texel_guard plugin rewrites fully transparent texels in
each frame's texture uploads as premultiplied (0, 0, 0, 1) before eframe
renders them (under one 8-bit level of difference). The desktop app
installs it only for DX12 on "Iris(R) Xe", the same adapter test wgpu
uses; PHOTOCRAFT_TEXEL_GUARD=1/0 forces it on or off.
The gpu example zero_block_probe reproduces the driver bug without the
UI: 630/1500 egui-style uploads read back wrong, 0/1500 with the guard.
Driving the release app (tool cycling, picker rescaled): 6/40
screenshots with red blocks before, 0/120 after.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
