fix(geochron): cache the map per panel size instead of thrashing between two

[ChuckBuilds]

The problem

The rendered map lived in a single _cached_map, and display() re-rendered whenever the cached layout's size differed from the display manager's:

if layout is None or self._cached_map is None \
        or layout["dw"] != dw or layout["dh"] != dh:
    self.update()

Vegas captures this plugin through the display-capture fallback at a narrower width than the panel — 153 px against 512 px on the rig this was found on. So the two sizes alternated, the one-entry cache missed every time, and each switch re-rendered the whole map from scratch. For a capture, that runs on the render thread.

Caught in the act:

15:42:15.016  Fallback: rendering at 153px instead of 512px
15:42:15.016  calling display()
15:42:15.305  display() returned              <- 289ms

Measured across a session at 271, 292, 559, 283, 287 and 639 ms per pass — a visibly stalled marquee.

Where the time goes

Timed the two halves directly:

	cost	depends on size?
compute_terminator	105 ms	no — it's a lat/lon grid
render_map_image	~150 ms	yes

So a third of it was recomputing something that didn't depend on the size that had just changed.

The fix

The terminator is computed once per update and shared across sizes. The map is cached per (width, height), and update() re-renders every size in use — on the update worker — so the render thread finds a warm image instead of building one.

Why not just refresh less often

The obvious alternative is to recompute every 30 minutes rather than every 45 seconds. That trades accuracy for the same saving, and it has a sharper edge: _draw_readout() draws a clock. It runs after the map is pasted, on every display() call, so a cached map doesn't freeze the time — but a throttled refresh would put the clock at risk, and the terminator would drift ~7.5° of longitude between rebuilds.

Caching per size costs nothing in accuracy, so the terminator keeps its configured update_interval. The test asserts the readout is still drawn on every display() and still reads the clock fresh, so a later change can't quietly fold it into the cached image.

Verification

Mutation-checked, all four caught:

• update() refreshing only the live size (the thrash returning)
• recomputing the terminator per size
• the render not populating the cache
• folding the clock into the cached image

Safety harness clean. Deployed to the rig it was diagnosed on; I'll post the before/after render-thread cost here.

[coderabbitai]

Important

Review available on request

• 🔍 Trigger review

Reviews should be triggered manually for repositories with fewer than 10 stars. Select Trigger review above or comment @coderabbitai review to review the latest changes. For a full review, comment @coderabbitai full review.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: c6b611f6-e949-47bc-86ed-fb8f893d3df6

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 32 complexity

Metric	Results
Complexity	32

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}