A Windows 11 borderless latency test should compare borderless and fullscreen under the same workload, not rely on one game’s FPS counter. In Windows 11, Microsoft’s Optimizations for windowed games can move compatible DX10/DX11 titles to flip-model presentation, which may reduce overhead and permit VRR/Auto HDR on supporting hardware. It does not guarantee that borderless always equals exclusive fullscreen, especially across APIs and monitors. Capture repeatable runs with identical frame caps and VRR settings, and note which metrics your capture method actually measures. That avoids treating software presentation timing as a direct button-to-photon result.
Choose between frame time, presentation timing, and input lag
Three useful measurements are frame time, presentation latency, and physical input-to-photon delay. Frame time is usually straightforward to log. PresentMon can capture timing metrics associated with presentation and display, but it is not a replacement for a high-speed camera or specialized latency analyzer that measures the full journey from a mouse click to photons on screen. Always specify which metric supports any conclusion.
Prepare an apples-to-apples test
- Choose a game with both borderless and fullscreen options. Note its graphics API (DX11, DX12 or Vulkan), Windows build, GPU driver, monitor, connection and refresh rate.
- Choose a fixed benchmark route or replay. Lock render resolution, upscaler mode, frame generation state, graphics quality and FPS cap across modes.
- Close unrelated overlays and recording tools unless the test explicitly evaluates them. Let shader compilation settle with warm-up runs.
- Use PresentMon or another documented ETW-based frame analysis tool to capture repeated 60–90-second passes. Label each CSV with game mode, display mode and driver version.
- Run a cycle such as borderless A → fullscreen B → borderless A to detect heat drift or transient processes masquerading as a mode difference.
- Compare median frame times, high-percentile frame-time spikes and presentation metrics rather than average FPS alone.
Check Windows-specific optimization states
Open Settings > System > Display > Graphics and record the global Optimizations for windowed games setting. Per-game exceptions are available under the title’s Options. Microsoft documents the feature primarily for DX10/DX11 windowed/borderless games; it may not alter a native DX12 application’s presentation path in the same way. Fully restart the game after changing the setting.
If Auto HDR is enabled, Windows may automatically enable windowed optimizations. Test HDR and optimization state as separate variables; changing color mode while changing presentation mode makes the experiment less controlled.
Read the results without overclaiming
A difference of 0.2 ms in one capture may be normal run-to-run variability. A repeated multi-millisecond penalty that persists across trials is more meaningful. If fullscreen lowers average frame time but borderless has fewer large spikes, decide which best serves the game’s actual use. A title at 60 FPS with a 16.7 ms average can still have uncomfortable 60–100 ms outliers; compare the tails of the distribution.
Mouse polling rate, display signal processing, VSync, frame queues and VRR ranges may affect input feel even when render times are identical. If a mode change affects VRR or tearing, that difference needs its own annotation, not a blanket assertion that Windows caused a CPU bottleneck.
When borderless may win
Borderless often gives faster desktop switching, better multitasking and compatibility with overlays. On supported DX10/DX11 paths, flip model can reduce the historical penalty associated with old blt presentation. Fullscreen can still be useful for a game with a specific display mode or engine optimization. The correct answer is per title, driver and Windows version.
Report frame delivery separately from input-to-photon latency
PresentMon’s console schema distinguishes MsBetweenPresents (spacing of the app’s Present calls), MsBetweenDisplayChange (visible frame-change spacing), and input-to-photon metrics such as MsClickToPhotonLatency when the capture supports them. Those values answer different questions. Do not rename a 99th-percentile frame time as mouse latency. Capture the same scene in exclusive fullscreen and borderless, note whether frame generation is enabled, and show both a pacing metric and the supported latency metric. PresentMon also documents limitations for OpenGL/Vulkan timing and some GPU execution measurements under hardware-accelerated GPU scheduling. A modest apparent difference can be within those measurement limits; repeat several runs instead of advertising a universal millisecond saving.
Example of an honest fullscreen versus borderless report
When recording a mode comparison, distinguish a metric derived from application Present calls from one based on displayed frames. Keep the same GPU driver, frame generation setting, VRR, V-Sync, frame cap and display refresh rate across modes. Export a PresentMon CSV for three matched runs in each mode; report the observed distribution and a clear statement of which input-to-display metrics were actually available. Do not call a frame-time percentile a direct mouse-to-screen latency result.
Sample report format (fields, not measured results): Game/build; Windows build; GPU/driver; monitor refresh/HDR/VRR; present mode; frame cap; test scene; capture duration; repeat number; median and 99th-percentile MsBetweenPresents; and, only when available and correctly interpreted, MsBetweenDisplayChange or MsUntilDisplayed. Use the same capture tool version for both modes and label each metric precisely.
PresentMon documents that present intervals and display intervals are different quantities. A display interval can be unavailable for certain frames or capture modes; missing output is not zero latency. Do not present a lower MsBetweenPresents value as a direct measurement of button-to-photon lag. Run multiple trials and disclose the spread before choosing a presentation mode.
Example reporting format (illustrative numbers only, not benchmark claims): borderless 16.8 ms median / 28 ms 99th-percentile displayed interval and exclusive fullscreen 16.7 ms / 27 ms across matching runs. If repeated distributions overlap, describe the result as inconclusive. Do not assign a universal 1 ms “latency saving” without hardware-appropriate input-to-display measurement.
Report a reproducible outcome
Document at least three captures per mode, GPU utilization, FPS cap, median FPS, 99th-percentile frame time and the title’s version. If the numbers overlap within noise, call the modes effectively equal under those conditions. Use the better mode for convenience and stability instead of claiming an unmeasured universal latency advantage.
