Read many pixels from one render in the e2e checks (#283)

On the WSL runner every __gm.pixelAt costs about 7 ms, three times as
much as on stein2. Each call renders the whole stage into a fresh
render texture and stalls until the GPU hands one pixel back. pixelRow
and several checks read hundreds of pixels that way. Module 05 spent
36.8 of its 40 s on these reads, module 04 11.3 of 20 s.

- stagePixels in src/ui/render.ts renders once around all points and
  reads them in one go. Only whole pixels at resolution 1 take that
  path. Anything else stays point by point.
- The hook __gm.pixels(points) exposes it, and pixelRow uses it.
- The loops in e2e 04, 05, 14 and 44 read their grids in one call.
- The old comment in pixelRow said a wider frame comes back resampled.
  That is not true. The colours match exactly, so the comment is gone.

Measured on the RTX (d3d12) and on stein2 (Intel, Vulkan): diff 0 at
10 680 points on each GPU. One screen row takes 4 to 18 ms instead of
2.4 to 9.9 s. The six affected modules need 32 s instead of 139 s
under WSL, faster than on stein2.

The rest of the gap is in Chromium's GPU process. perf puts three
quarters of its time in the drivers (NVIDIA D3D12, Mesa d3d12, dxg).
Four browser and Mesa settings were measured, none helped.

Tests:
- ./check.sh on melektaus-atx: 195 files, 2827 tests, CHECK EXIT 0 (+4)
- e2e 1-16,30,37,44,58 under WSL: ALL PASSED, 587 checks
- counter-check: a wrong index in stagePixels fails the unit test

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
adminandClaude Opus 5.5 committed 2026-09-29 22:07:53 +02:00
1 parent 857e23c69b
commit ffedd81803
8 files changed
+132 -36

No files matched your search

+1
View File
@@ -13,6 +13,7 @@ export {
requestRender,
resetRenderLoop,
stagePixel,
stagePixels,
} from './render';
export {
drawBand,
+29 -1
View File
@@ -132,6 +132,34 @@ export function resetRenderLoop(): void {
/** The colour actually on screen at a point, as `#rrggbb` – what was drawn, not what the model says. */
export function stagePixel(app: Application, x: number, y: number): string {
const { pixels } = app.renderer.extract.pixels({ target: app.stage, frame: new Rectangle(x, y, 1, 1) });
return colourAt(pixels, 0);
}
/**
* The colours at many points from one render and one readback, in the order given – the same
* answers as `stagePixel` point by point. Each extract builds, fills and frees a render texture of
* its own and stalls until the GPU is done; a check reading hundreds of pixels paid that hundreds
* of times (25 s of one step behind WSL's d3d12 driver, where a single read costs ~7 ms).
*
* Only whole pixels at a resolution of 1 go through the shared frame. Anything else keeps the
* point-by-point read, whose sampling position this would otherwise have to reproduce.
*/
export function stagePixels(app: Application, points: readonly { x: number; y: number }[]): string[] {
const whole = points.every((p) => Number.isInteger(p.x) && Number.isInteger(p.y));
if (points.length < 2 || !whole || app.renderer.resolution !== 1)
return points.map((p) => stagePixel(app, p.x, p.y));
const left = Math.min(...points.map((p) => p.x));
const top = Math.min(...points.map((p) => p.y));
const width = Math.max(...points.map((p) => p.x)) - left + 1;
const height = Math.max(...points.map((p) => p.y)) - top + 1;
const { pixels } = app.renderer.extract.pixels({
target: app.stage,
frame: new Rectangle(left, top, width, height),
});
return points.map((p) => colourAt(pixels, ((p.y - top) * width + (p.x - left)) * 4));
}
function colourAt(pixels: ArrayLike<number>, at: number): string {
const hex = (value: number | undefined) => (value ?? 0).toString(16).padStart(2, '0');
return `#${hex(pixels[0])}${hex(pixels[1])}${hex(pixels[2])}`;
return `#${hex(pixels[at])}${hex(pixels[at + 1])}${hex(pixels[at + 2])}`;
}