Limits of runtime resolution changes in Monogame windowed mode for accessibility

Direct Answers

1. Render target retention: Calling ApplyChanges() after updating PreferredBackBufferWidth/Height clears the current back buffer. Any content drawn to the back buffer is lost unless you first copy it to a texture.
2. Client size vs. requested dimensions: After ApplyChanges(), Window.ClientBounds reports the requested dimensions, but the actual window includes OS non‑client borders (title bar, borders). The usable drawing area matches ClientBounds, not the outer window size.
3. DPI scaling regressions: MonoGame does not automatically adjust for OS DPI scaling in windowed mode. The back buffer is created at the logical resolution, so UI elements appear smaller on high‑DPI displays unless you manually scale them. A regression in MonoGame 3.7/3.8 can trigger a graphics device reset when changing the back buffer size, causing a brief flicker and requiring all custom render targets to be recreated.

Confirmed Behavior

GraphicsDeviceManager.ApplyChanges internally calls GraphicsDevice.Reset, which detaches and resets all attached render targets. Developers must recreate or re‑initialize any custom render targets after the call. For layout calculations, always use Window.ClientBounds rather than Window.Size, because the latter includes window decorations that do not affect rendering.

Platform and Version Assumptions

• Behavior described is based on Windows DesktopGL backend; macOS and Linux may differ due to platform‑specific graphics back‑ends.
• MonoGame 3.6, 3.7, and 3.8 share the core reset behavior, but 3.7+ introduced a device‑reset regression on windowed back‑buffer changes.
• High‑DPI scaling can cause pixel art to blur; consider higher‑resolution textures or vector UI for accessibility.

Verification Steps

1. Create a test project, set PreferredBackBufferWidth/Height to 800×600, call ApplyChanges(), render a solid color, then change to 1280×720, call ApplyChanges(), and confirm the back buffer is cleared (visible transition or pixel check).
2. Log Window.ClientBounds and Window.Size before and after ApplyChanges() to verify client bounds match requested dimensions and that the overall window size includes non‑client borders.
3. Run on a Windows machine with 150% DPI scaling, place a UI element at a fixed logical coordinate, and measure its pixel size on screen to confirm it is smaller than expected unless manually scaled.

Missing Diagnostic Detail

Which platform (Windows, macOS, Linux) and MonoGame version are you targeting? The behavior of non‑client borders and DPI handling varies by platform, and the device‑reset regression is specific to 3.7+ on Windows.