Describe why painting a big tilemap stays smooth (#347)

Tilemaps gets a section on the third round of painting speed, with
the four causes and the measured frame rates. Development counts
1863 checks.
admin committed 2026-10-07 16:55:29 +02:00
1 parent 133af19725
commit 0e59e3797f
2 files changed
+21 -1

No files matched your search

+1 -1
@@ -19,7 +19,7 @@ php tests/php/accounts.test.php # the API's accoun
php tests/php/snapshots.test.php # the snapshot store (#231), the same way php tests/php/snapshots.test.php # the snapshot store (#231), the same way
php tests/php/releases.test.php # the release store (#266), the same way php tests/php/releases.test.php # the release store (#266), the same way
php tests/php/files.test.php # uploaded files in a folder per account (#344), the same way php tests/php/files.test.php # uploaded files in a folder per account (#344), the same way
node tools/seed-e2e.mjs && node tools/e2e.mjs # 1862 editor checks, screenshots in /tmp/gm-e2e-*.png node tools/seed-e2e.mjs && node tools/e2e.mjs # 1863 editor checks, screenshots in /tmp/gm-e2e-*.png
GM_STEPS=20 node tools/e2e.mjs # or 1-12, or 6,20 — a subset while working on one step GM_STEPS=20 node tools/e2e.mjs # or 1-12, or 6,20 — a subset while working on one step
./e2e.sh start [GM_STEPS] # the same run detached, see below ./e2e.sh start [GM_STEPS] # the same run detached, see below
./e2e.sh status # live progress, or the last run's result ./e2e.sh status # live progress, or the last run's result
+20
@@ -355,6 +355,26 @@ Measured in Play on the 30x18 map of the reference project with 222 entities, pe
main thread of a slow machine: Physics 2.64 to 0.97 ms, Drawing 6.89 to 2.56 ms. The same scene main thread of a slow machine: Physics 2.64 to 0.97 ms, Drawing 6.89 to 2.56 ms. The same scene
without the map and its crates takes 0.30 and 1.63 ms. without the map and its crates takes 0.30 and 1.63 ms.
A third round (#347) took out what **painting** cost on top of that:
- Each frame of a stroke previews the model, and the asset and hierarchy panels built every row
anew on it. Every label became a new text, and every text a new upload to the GPU. `ListView`
now keeps a row whose item draws the same (`sameListItem`) and builds only the ones that changed.
- The brush drew the whole scene on every pointer event, on top of the preview and of `animate`.
Now the preview draws what a stroke changed, once a frame. The rectangle tool asks for one
drawing a frame for its box. `animate` asks just before the frame is drawn instead of in the
tick, so a frame with a preview in it is drawn once.
- Where the scene view's symbols stand (`layoutSymbols`) is kept while no anchor moves.
- A layer's cells are read once per content into an index by place (`layerCells`), and the tiles
and the blocking cells find their neighbours there instead of building a key string for each.
Measured with a brush stroke on a copy of a project with a 60x60 map on three layers and fifty
objects (Chrome, slow machine): 20 to 39 fps before, 47.5 after, against 55 to 57 fps without
painting. The stroke drew 2012 labels again before and none after, and the scene 1.32 times a
frame before and once after. One painted cell cost the scene view 28 ms headless before and 16 ms
after, on the same map doubled to 120x120 109 ms before and 49 ms after. That last part still grows
with the map: a painted cell works out the tiles and blocking cells of the whole map again.
A frame still costs what it touches: an object standing **inside** many outlined cells is tested A frame still costs what it touches: an object standing **inside** many outlined cells is tested
against each of them, so an outline of a hundred corners around every cell of a lake is dearer than against each of them, so an outline of a hundred corners around every cell of a lake is dearer than
a few around its shore. Draw as few corners as the shape needs. a few around its shore. Draw as few corners as the shape needs.