Commit fe85f6f
Exoridus
fix(webgpu): correct sprite index buffer size and avoid mid-pass growth
Three related bugs in WebGpuSpriteRenderer that surface together when
the sprite count exceeds initialBatchCapacity (32):
1. Index buffer was allocated with
size: indexData.byteLength * Uint32Array.BYTES_PER_ELEMENT
indexData.byteLength is already bytes, so the buffer ended up 4x
larger than intended. Benign alone, but wastes memory.
2. _ensureBatchCapacity was called inside the draw loop, after
setVertexBuffer and setIndexBuffer were already recorded on the
render pass. When a batch exceeds the current capacity, the method
destroys the old GPU buffers and creates new ones — the pass then
holds bindings to destroyed buffers, producing
- "Index range (first: 0, count: N) does not fit in index buffer
size (3072)" (the initial 32-sprite buffer)
- "[Buffer (unlabeled)] used in submit while destroyed"
3. Hotfix above: walk all batches up front, find the largest sprite
count, and ensureBatchCapacity once before begin of the render
pass. All subsequent setVertexBuffer/setIndexBuffer bindings stay
valid throughout the pass.
The drawIndexed is the same as before — only the growth path moves.1 parent 753c2ad commit fe85f6f
1 file changed
Lines changed: 19 additions & 2 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
299 | 299 | | |
300 | 300 | | |
301 | 301 | | |
| 302 | + | |
| 303 | + | |
| 304 | + | |
| 305 | + | |
| 306 | + | |
| 307 | + | |
| 308 | + | |
| 309 | + | |
| 310 | + | |
| 311 | + | |
| 312 | + | |
| 313 | + | |
| 314 | + | |
| 315 | + | |
| 316 | + | |
| 317 | + | |
| 318 | + | |
| 319 | + | |
302 | 320 | | |
303 | 321 | | |
304 | 322 | | |
| |||
338 | 356 | | |
339 | 357 | | |
340 | 358 | | |
341 | | - | |
342 | 359 | | |
343 | 360 | | |
344 | 361 | | |
| |||
388 | 405 | | |
389 | 406 | | |
390 | 407 | | |
391 | | - | |
| 408 | + | |
392 | 409 | | |
393 | 410 | | |
394 | 411 | | |
| |||
0 commit comments