How DWM Handles Mixed Refresh Rate Displays

Running multiple monitors with mismatched refresh rates—such as a 144Hz gaming monitor paired with a secondary 60Hz display over DisplayPort—historically caused severe stuttering and refresh-rate clamping in Windows. Modern versions of Windows resolve this through architectural updates to the Desktop Window Manager (DWM) and the Windows Display Driver Model (WDDM). By decoupling the composition clock from a single master display, modern DWM uses per-monitor presentation loops and hardware overlays to drive each DisplayPort pipeline at its native frequency.

The Legacy Problem: Global VSync Locking

In older versions of Windows (prior to Windows 10 version 2004 and WDDM 2.7), DWM used a centralized, global composition loop tied to the VSync signal of a single primary monitor. If an application displayed hardware-accelerated, constantly updating content (such as a video or hardware-accelerated browser) on a secondary 60Hz display, DWM often throttled its internal tick rate to match the lowest common denominator.

This synchronization bottleneck meant that a 144Hz monitor would drop frames or stutter, effectively falling back to 60Hz presentation behavior whenever any animated surface ran on the slower display.

Per-Monitor Refresh Cadence in Modern DWM

With the introduction of WDDM 2.7, Microsoft redesigned DWM's presentation pipeline to manage independent timing threads for each attached display. DisplayPort architecture naturally accommodates this, as each physical port operates on a dedicated display pipeline and timing controller within the GPU.

Instead of waiting for a single shared VSync signal:

  • DWM listens to the discrete vertical blanking (VBLANK) hardware interrupts generated by each individual DisplayPort connection.
  • An independent composition cycle is scheduled for each monitor.
  • A high-refresh display's composition engine ticks and presents frames every 6.94 milliseconds (at 144Hz), while the secondary display’s loop ticks every 16.67 milliseconds (at 60Hz).

DXGI Flip Model and Buffer Swapping

For this system to function cleanly, applications must use modern DirectX Graphics Infrastructure (DXGI) presentation modes, specifically DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL or DXGI_SWAP_EFFECT_FLIP_DISCARD.

Under the Flip model, the application renders to a swap chain buffer and hands ownership of that buffer directly to DWM without copying memory. DWM samples the newest completed frame available at the moment a specific monitor’s VBLANK interrupt fires.

  • If an application is running at 144 FPS on the primary monitor, DWM consumes 144 frames per second for that output.
  • If an application runs at 60 FPS on the secondary monitor, it pushes frames at its own rate without stalling the swap chain of the primary display.

Multiplane Overlays (MPO)

Modern GPUs and drivers leverage Multiplane Overlays (MPO) to reduce the composition burden entirely. When MPO is active, DWM can instruct the GPU’s display engine to scan out an application window directly from its own surface rather than compositing it into a shared desktop framebuffer.

By bypassing desktop composition for full-screen or focused borderless-windowed applications, the GPU reads the application buffer directly onto the high-refresh DisplayPort pipeline. This isolates the high-refresh monitor from whatever desktop activity or video playback is occurring on the secondary monitor.

Windows Spanning Across Mismatched Monitors

When a single window is dragged so that it spans across two displays with different refresh rates, DWM must resolve the conflict:

  1. Dominant Display Determination: DWM determines which monitor contains the larger portion of the window surface.
  2. Target Rendering: The application renders at the target refresh rate of the dominant display.
  3. Scanout Allocation: As DWM samples the rendered surface, the DisplayPort controller for the high-refresh monitor displays every frame presented. Meanwhile, the DisplayPort controller for the 60Hz monitor skips or drops intermediate frames to match its 60Hz scanout rate.

This separation of application rendering, compositor sampling, and hardware scanout allows Windows DWM to maintain fluid animation on high-refresh DisplayPort monitors without being degraded by lower-frequency adjacent screens.