The map draws on every step of the rate wheel

The renderer walks a sixteen-step rate wheel: one step per full pass over
the gauge list, shifted right each pass and reset at the bottom. A gauge
redraws only on the step its configured rate names, so the map - on one
step - waited a whole turn of the wheel however cheap its redraw was.

With the frame budget fixed the wheel turns about fifty times a second
and one-in-sixteen would be tolerable. It is still the wrong shape for
the map: the thing a pilot reads to navigate should not be the display
that updates least often, and RP412MAPRATE says how many of the sixteen
steps it draws on. Sixteen by default, one for the old data-driven
behaviour. Each extra step costs one gauge's redraw against a pass that
runs ninety of them, which measured as nothing.

The write has to be QUALIFIED, and that is worth recording because it
cost hours. GPS's constructor takes its rate as a parameter also called
'rate', which shadows the inherited Gauge::rate for the whole body - so a
bare assignment sets the parameter and leaves the member holding whatever
the gauge data asked for. oldRate is not shadowed, so it took the value,
and the pair then disagreed: rate=2000, old=ffff. That looked exactly
like something writing the member from outside, and there is no such
writer - Gauge touches rate in three places, none of which can produce
that pair. A hardware write-watch on the member settled it by reporting
an address on the STACK.

Also here, the terrain-arrival work on the map background. It draws one
placement into the cached picture when the static bounds are unchanged,
and rebuilds the whole thing only when they move - the bounds set the
scale, and the scale is what everything already on the picture was drawn
at. It is honest to say this fires rarely: the logs show terrain arriving
in one burst at mission load, not streaming in as you drive, so the
incremental path is mostly insurance. What it does close is real, though
- departures now order a rebuild. Nothing listened for those before, and
they had been swept up by the rebuild the next ARRIVAL ordered, which on
a track whose terrain all arrives at load is a rebuild that never comes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

RP_L4/RPL4ENVIRON.cpp

@@ -210,6 +210,14 @@ namespace
 "# rate.\n"
 "RP412GAUGESLICE=2\n"
 "\n"
+"# How many times the map redraws per turn of the gauge rate wheel, 1 to\n"
+"# 16. The renderer gives each gauge one step of a sixteen-step wheel and\n"
+"# a gauge redraws only on its own step, so a map left on one step waits a\n"
+"# whole turn. 16 = redraw on every step (default); 1 = whatever the gauge\n"
+"# data asks for, which is how it behaved before this existed. Each step\n"
+"# costs one map redraw against a pass that runs ninety gauges.\n"
+"RP412MAPRATE=16\n"
+"\n"
 "# 1 = log how many times a second every cockpit display is actually\n"
 "# refreshed, to rpl4.log. Watching the screen cannot tell a display that\n"
 "# has stopped refreshing from one whose picture simply is not changing.\n"