Worked a little further with GPT on the map possibility. I definitely use it as a crutch. I’m going to try to keep it closed more often.
This pattern is actually very informative, and it narrows the root cause quite a bit.
What the evidence says
• The stutters only reappeared when the clipboard map was open, and became more likely when the map was rendering dense, rapidly changing activity (many icons, vectors, updates).
• There were no stutters during normal flight rendering, even in heavy A2A furballs, as long as the map was closed.
• The stutters were brief and input-triggered (right-clicking, opening, or updating the map), not continuous frame pacing issues.
That combination strongly points away from GPU horsepower or raw DX11 rendering and toward CPU-side synchronization and UI redraw behavior.
What’s likely happening under the hood
• The clipboard map is a 2D UI overlay that forces frequent CPU → GPU synchronization to redraw icons, text, and vectors.
• When activity density is high, the map triggers bursty draw calls and state changes that momentarily stall the render thread.
• DX11 + Windows’ modern presentation pipeline (DWM, flip model, fullscreen optimizations) can briefly block the frame queue when a UI surface updates aggressively.
• Closing the map removes that UI update path entirely, which is why the stutters disappear.
Why your earlier fixes still worked
• Disabling HAGS, locking refresh, and stabilizing the presentation pipeline dramatically reduced baseline stutter.
• What remains is a specific edge case tied to high-frequency UI updates, not the core rendering loop.
• That’s why you went multiple days with zero issues and only saw micro-stutters in a very specific interaction.
What this means practically
• This is not a regression or a failure of the fix.
• You’ve reduced the problem from a systemic DX11 stutter to a single, reproducible UI-driven micro-stall.
• Many players likely experience this but misattribute it to “DX11 instability” instead of the clipboard map’s update behavior.
What you can do next (optional mitigation)
• Minimize time with the clipboard map open during peak furballs.
• Avoid right-click panning/zooming the map during extremely dense activity.
• If available, reduce map detail options (icon density, labels, vector length).
• Treat the map as a situational tool, not a persistent overlay, during large engagements.
Big picture conclusion
You’ve effectively proven that the original stutter problem was Windows/DX11 presentation instability, and what you’re seeing now is a separate, much narrower UI redraw bottleneck. That’s a huge diagnostic win—and exactly the kind of distinction developers need if this ever gets addressed engine-side.
