Tracking ticket — defer to actual WebGPU port
A small refactor identified during 19.7 prep that's deliberately not being landed in 19.7 because the right shape depends on a real WebGPU consumer.
Today (imperative WebGL)
Each batcher (QuadBatcher, LitQuadBatcher, MeshBatcher, PrimitiveBatcher, and the tilemap GPU renderer) configures its vertex layout by emitting a sequence of gl.vertexAttribPointer calls — see Batcher.setVertexAttributes(gl, attributes, stride):
gl.vertexAttribPointer(0, 3, gl.FLOAT, false, stride, 0); // aVertex (vec3)
gl.enableVertexAttribArray(0);
gl.vertexAttribPointer(1, 2, gl.FLOAT, false, stride, 12); // aRegion (vec2)
gl.enableVertexAttribArray(1);
gl.vertexAttribPointer(2, 4, gl.UNSIGNED_BYTE, true, stride, 20); // aColor (uint8x4 normalized)
gl.enableVertexAttribArray(2);
WebGPU equivalent (declarative)
const layout = {
arrayStride: 24,
attributes: [
{ shaderLocation: 0, format: "float32x3", offset: 0 }, // aVertex
{ shaderLocation: 1, format: "float32x2", offset: 12 }, // aRegion
{ shaderLocation: 2, format: "unorm8x4", offset: 20 }, // aColor
],
};
Same information, different shape. WebGPU's descriptor is passed at pipeline-creation time, not per-draw.
Refactor sketch
A backend-neutral descriptor each batcher carries once:
const QUAD_VERTEX_LAYOUT = {
stride: 24,
attributes: [
{ name: "aVertex", type: "f32x3", offset: 0 },
{ name: "aRegion", type: "f32x2", offset: 12 },
{ name: "aColor", type: "u8x4n", offset: 20 }, // n = normalized
],
};
- WebGL backend: helper iterates the descriptor and emits the matching
gl.vertexAttribPointer calls.
- WebGPU backend: helper translates to the declarative
arrayStride / attributes shape above.
Why deferred
The right type vocabulary (f32x3 / unorm8x4 / etc.) depends on:
- What WebGPU's
GPUVertexFormat enum actually supports.
- What WebGL formats each batcher uses today (need to audit
Batcher.setVertexAttributes calls and the supplied attributes shape).
- What the future WebGPU equivalent of
MaterialBatcher would need.
Designing the descriptor vocabulary up-front, without a real WebGPU consumer to validate against, risks committing to a shape that needs reshuffling. Better to land this as one of the first commits of the actual WebGPU port — that way the abstraction gets validated against a real implementation rather than designed in the abstract.
Cross-refs
Tracking ticket — defer to actual WebGPU port
A small refactor identified during 19.7 prep that's deliberately not being landed in 19.7 because the right shape depends on a real WebGPU consumer.
Today (imperative WebGL)
Each batcher (
QuadBatcher,LitQuadBatcher,MeshBatcher,PrimitiveBatcher, and the tilemap GPU renderer) configures its vertex layout by emitting a sequence ofgl.vertexAttribPointercalls — seeBatcher.setVertexAttributes(gl, attributes, stride):WebGPU equivalent (declarative)
Same information, different shape. WebGPU's descriptor is passed at pipeline-creation time, not per-draw.
Refactor sketch
A backend-neutral descriptor each batcher carries once:
gl.vertexAttribPointercalls.arrayStride / attributesshape above.Why deferred
The right type vocabulary (
f32x3/unorm8x4/ etc.) depends on:GPUVertexFormatenum actually supports.Batcher.setVertexAttributescalls and the suppliedattributesshape).MaterialBatcherwould need.Designing the descriptor vocabulary up-front, without a real WebGPU consumer to validate against, risks committing to a shape that needs reshuffling. Better to land this as one of the first commits of the actual WebGPU port — that way the abstraction gets validated against a real implementation rather than designed in the abstract.
Cross-refs
src/video/webgl/batchers/carries its ownsetVertexAttributescall shape — audit those first when picking the descriptor type vocabulary.