4-up performance profile: per-instance render caps + right-sized JVM heaps (GPU saturated, VRAM carve-out full)

[aradanmn]

Live 4-instance measurement on-Deck (2026-07-06, during v1.1.1 stage3): GPU 100% busy, VRAM 980/1024MB (spilling to GTT), RAM 12.9/14.8GB with swap engaged (4 JVMs ≈ 6.3GB RSS, each -Xmx3072m), CPU load ~1.9/8 threads at 54°C. Operator-visible stutter; CPU/thermals innocent.

Proposal — same options.txt mechanism as the #32 sound profile, applied per slot at instance creation:

• maxFps: ~40 for 4-up quadrants (640x360 — invisible loss, large GPU relief)
• renderDistance: ~8 (biggest single lever), simulationDistance: ~6
• JVM: -Xmx2048m for quadrant instances (frees up to 4GB potential, cuts swap pressure)
• Consider scaling: fullscreen/1-up keeps generous settings; profile tightens as slot count grows (would need reflow-time adjustment or a static 'party' profile at creation)
• Document (not automate) the BIOS UMA 1→4GB option with the RAM-pressure caveat.

[aradanmn]

Benchmark data landed via PR #94 (merged b130209): the standard perf mod set + G1GC heap flags measured against main under the controlled v2 A/B protocol — 4P median +25%, 1%-lows ~+40%, 2P flight lows ~2x, RSS −350-840MB at 1-3P, and 4P memory well inside gates on both installs (v1's 1.4GB-swap wall proved protocol-borne, not install physics — full analysis in docs/BENCH-AB-2026-07-18.md). Remaining item from this issue's original scope: per-instance RENDER caps were not implemented or measured — the GPU carve-up at 3-4P (~300fps steady per screen now) suggests they may be unnecessary, but that's a maintainer scope call for closing or trimming this issue.

[aradanmn]

Direction change from the owner (supersedes the earlier close recommendation): investigate frame-rate capping to display refresh instead of closing. Rationale: BENCH-AB measured 300-600fps per screen into a 60Hz panel at 92-94% CPU (4P) — capping converts discarded frames into thermal/CPU headroom and better 1%-lows. Two candidate mechanisms to A/B with the existing bench harness: (1) options.txt maxFps:60 per instance (installer already writes options.txt; compositor-independent), (2) enableVsync:true (swap-interval semantics under the nested compositor need verification for 4 simultaneous GL windows, adds input latency). Scheduled as a v1.2 experiment alongside the PLAN-V1.2 M4 perf gate.

[aradanmn]

Frame-cap half delivered — #113

The maxFps-to-refresh portion of this issue is implemented and merged via #113.

What shipped: each instance's maxFps is now set at launch time to the live
display refresh (dynamic, per connected display) instead of the hard-coded 120 —
sampled in the host context, carried across the re-exec, written to every active
slot's options.txt. On by default (MCSS_CAP_FPS_TO_REFRESH); fallback 60, clamp
[30, 360].

On-Deck validated (Steam Deck OLED, Game Mode, real modset + Paper server):

Mode	Detected	options.txt	MC F3
Handheld (OLED)	90	maxFps:90	T: 90
Docked (external)	60	maxFps:60 ×4	T: 60 (pinned)
4-up docked, capped 60	—	all 4 = 60	aggregate CPU ≈42% vs the BENCH-AB uncapped 92–94%

That aggregate-CPU drop under real 4-player load is the thermal/headroom win this
issue was opened for. The open pre-merge question — does the xrandr-under-gamescope
probe read the real panel refresh in Game Mode — is answered yes (it tracks the
active output docked↔handheld; only needed a round-not-floor fix for gamescope's
89.89/59.96 advertisement). No DRM fallback required. Runbook + results in
docs/VERIFY-70-MAXFPS.md.

Still open under this issue (not in #113):

• Per-slot-count render-cap variation (renderDistance, sim distance) as player
  count rises.
• Right-sized JVM heaps per instance (the "VRAM carve-out full / GPU saturated"
  angle).

Leaving this issue open to track that remaining scope.

(Aside: on-Deck launches also needed a workaround for an unrelated MC 26.1.2
LWJGL-SDL/GLFW classpath regression — tracked in #114.)