perf: throttle WMS playback requests to prevent overlapping GeoServer tile rendering

[mluena]

Overview

During timeline playback the map called updateParams({ DIM_DATE }) on every tick (2.5s), regardless of whether the previous batch of tiles had finished. OpenLayers does not cancel in-flight tile requests on updateParams(), so GeoServer kept rendering tiles the frontend then discarded — wasted server work whenever the server ran slower than the playback interval.

Two commits, and the second one is the important one.

perf: throttle WMS date changes against in-flight tiles implements the ticket as written: src/components/map/layers/buffered-tile-wms.tsx counts in-flight tiles via tileloadstart / tileloadend / tileloaderror, and a date arriving while tiles load is stored and applied once the source goes idle, coalescing several ticks into one request.

On its own that fixes the server load but makes playback stutter. The Timeline advances the date every 2.5s unconditionally, so the clock and the map decouple: the slider and date label keep moving while the map holds and then jumps, the coalesced dates never render, and the value tooltip (which reads date from state, not from the source) shows a date the map is not displaying.

perf: pace timeline playback on map tile readiness fixes that by making the clock wait for the map:

• The WMS layers publish their in-flight tile state to mapTilesLoadingAtom (src/app/store.tsx), keyed per instance, derived into areMapTilesLoadingAtom.
• Both timelines now step through usePacedTimelineStep (src/hooks/timeline.ts) instead of a bare useInterval. A step is held while tiles are loading and fires as soon as they settle; time already spent loading counts towards the interval, so the cadence is max(2.5s, tile load time).
• Slider, date label, tooltip and rendered tiles stay on the same date, and no date is skipped.

The layer-level coalescing stays in place as a safeguard for date changes that do not come from playback (manual scrubbing, tick clicks). Its 10s guard (PENDING_DATE_TIMEOUT) also releases the loading flag, so a tile whose load event never arrives cannot stall the timeline.

Deviation from the ticket: OEMC-443 asks for the change to be isolated to buffered-tile-wms.tsx with the Timeline untouched. That constraint is what produced the stutter — coalescing at the layer while the clock keeps running cannot keep the slider and the map on the same date. Noted on the ticket.

Designs

N/A

Testing instructions

1. Open /explore, activate a layer with a time dimension, open DevTools → Network, filter by GetMap.
2. Play the timeline. Requests should come in non-overlapping batches — a new DIM_DATE batch only starts after the previous one settles, no interleaving.
3. Throttle the network ("Slow 3G") and play again. Playback should slow down rather than skip: every date in the range still renders, the slider moves in step with the map, and no requests pile up.
4. Back on a fast connection, confirm the cadence is still ~2.5s per step.
5. Scrub the timeline manually and click individual ticks while tiles load — the map should end on the last date selected.
6. No visual regression: old tiles stay visible until new ones load (no blink).
7. Hover the map to open the value tooltip, then play — the tooltip value matches the date the map is showing.
8. Compare mode: enable it, confirm the main timeline is still paused and the comparative timeline plays with the same pacing.

Not verified at runtime by the author.

Feature relevant tickets

OEMC-443

---

Checklist before submitting

• Meaningful commits and code rebased on develop.
• Update CHANGELOG
• If this PR adds feature that should be tested for regressions when
  deploying to staging/production, please add brief testing instructions
  to the deploy checklist

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
oemc	Ready	Preview	Aug 5, 2026 8:54am