A large map takes 10–15 s to load: cut smaller zoom levels, show the thumbnail first #1282

New issue

Closed

opened 2026-10-30 03:43:03 +00:00 by claude-bot · 1 comment

claude-bot commented

2026-10-30 03:43:03 +00:00

Collaborator

Found by the owner on dev (4.6.2-rc2, 2026-10-30), with a map uploaded deliberately at the largest size allowed: Exadia, 8192 × 6144, which is exactly MAP_MAX_PIXELS. Opening it takes about 10–15 s before every tile is drawn. Small maps (12–24 tiles) are quick.

Cause (measured on dev):

app/tasks/map_tiles.py cuts one zoom level, native resolution in 256 px tiles (its docstring says the downsampled levels were left for later). MapCanvas sets minNativeZoom: 0, maxNativeZoom: 0, so a map opened zoomed out to fit fetches every native tile and scales it down: 768 tiles for Exadia, roughly 20 MB.
Every tile goes through download_map_tile, which runs load_roster and _viewable_map (database queries) before its X-Accel-Redirect. Dev runs uvicorn with --workers 2, so 768 checks queue. On prod, a uvicorn child died during the first tile burst of a 4096² map (noted on #1251).

Plan:

A real pyramid: the worker also cuts z = -1, -2, … (each half the last) until the map fits in one tile. MapCanvas sets minNativeZoom to the lowest level the map has. A fitted view then needs roughly 20–40 tiles. Existing maps get theirs from a one-off backfill task, like backfill_map_thumbs. Export and import are unaffected: tiles never travel and are cut again on import.
Thumbnail first: draw the existing 1024 px thumbnail as an image overlay under the tile layer, so the map appears at once and sharpens as tiles arrive.
Only if 1 isn't enough: a short-lived per-(user, map) cache of the audience decision. Trade-off: narrowing a map's audience takes up to the cache's lifetime (e.g. 30 s) to reach someone already viewing it.

Measure: time to first full view of Exadia on dev before and after, and the tile requests for a fitted view.

Release: the owner to choose 4.6.2 (an rc3) or 4.6.3.

Found by the owner on dev (4.6.2-rc2, 2026-10-30), with a map uploaded deliberately at the largest size allowed: **Exadia, 8192 × 6144**, which is exactly `MAP_MAX_PIXELS`. Opening it takes about 10–15 s before every tile is drawn. Small maps (12–24 tiles) are quick. **Cause (measured on dev):** - `app/tasks/map_tiles.py` cuts **one zoom level**, native resolution in 256 px tiles (its docstring says the downsampled levels were left for later). `MapCanvas` sets `minNativeZoom: 0`, `maxNativeZoom: 0`, so a map opened zoomed out to fit fetches **every** native tile and scales it down: **768 tiles** for Exadia, roughly 20 MB. - Every tile goes through `download_map_tile`, which runs `load_roster` and `_viewable_map` (database queries) before its `X-Accel-Redirect`. Dev runs uvicorn with `--workers 2`, so 768 checks queue. On prod, a uvicorn child died during the first tile burst of a 4096² map (noted on #1251). **Plan:** 1. **A real pyramid:** the worker also cuts z = -1, -2, … (each half the last) until the map fits in one tile. MapCanvas sets `minNativeZoom` to the lowest level the map has. A fitted view then needs roughly 20–40 tiles. Existing maps get theirs from a one-off backfill task, like `backfill_map_thumbs`. Export and import are unaffected: tiles never travel and are cut again on import. 2. **Thumbnail first:** draw the existing 1024 px thumbnail as an image overlay under the tile layer, so the map appears at once and sharpens as tiles arrive. 3. **Only if 1 isn't enough:** a short-lived per-(user, map) cache of the audience decision. Trade-off: narrowing a map's audience takes up to the cache's lifetime (e.g. 30 s) to reach someone already viewing it. **Measure:** time to first full view of Exadia on dev before and after, and the tile requests for a fitted view. Release: the owner to choose 4.6.2 (an rc3) or 4.6.3.

claude-bot added this to the v4.6.2 - The map, as planned milestone

2026-10-30 03:44:09 +00:00

claude-bot commented

2026-10-30 03:44:09 +00:00

Author

Collaborator

The owner, 2026-10-30: this goes in 4.6.2, as rc3. On hold until they've finished testing rc2, so it can be queued with whatever else that testing turns up.

The owner, 2026-10-30: this goes in **4.6.2, as rc3**. **On hold** until they've finished testing rc2, so it can be queued with whatever else that testing turns up.

claude-bot referenced this issue

2026-10-30 03:53:51 +00:00

4.6.2-rc2 review: the owner's findings, for rc3 #1283

claude-bot referenced this issue from a pull request that will close it,

2026-10-30 04:12:49 +00:00

fix(webapp): large maps load from a tile pyramid; rc2 review fixes (#1282, #1283) #1284