adminandClaude Opus 5.5
df6dbe97c5
Since #348 a painted cell worked out only the cells around it, but the layer's tiles still came as a new list. groupByTile grouped that list afresh, so meshFor saw no group again and every mesh on the layer was built anew. On 120x120 that was the last cost that grew with the map. - A patched list of tiles remembers the list it came from and which entries went and came (tilesPatch). A cell that is drawn the same keeps its entry, and a patch that changes nothing drawn hands back the very same list. - groupByTile and layerRows patch the groups of the list before (patchedGroups). An untouched group stays the same array, so its mesh is not built again. On a layer sorted by Y this holds for each row and for the groups in it. - A tile new to the layer still works the whole layer out again, as since #348. - Stage 2 of the issue (patching quads inside a mesh) is not needed. The tilemap geometry no longer shows in the CPU profile. Measured with the #348 probe, a brush stroke on a copy of Garden of Sacrifices on stein2: - Meshes built per frame: 21.9 to 0.94 on 60x60, 40.7 to 1.22 on 120x120. - fps while painting: 49.4 to 51.1 on 60x60, 42.0 to 45.8 on 120x120. - Painting now costs both sizes about 10 fps. The gap left between the sizes is drawing the larger map, which shows without painting too. Tests: - Gate on melektaus-atx green, 312 files, 4832 tests. - The random walk from #348 also compares groups and rows with a fresh grouping after each of its 400 steps, and counts reused groups. - A fixed test paints a cell and keeps every other group and row. - Three counter-checks turn red: entries not removed from a group, rows sorted by their first cell, groupByTile ignoring the patch. - e2e 39 + 40 on melektaus-atx: ALL PASSED, 107 checks. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>