Dual Monitors: How Playing Video Impacts Gaming Benchmarks
Running a secondary monitor with a playing video during a gaming benchmark significantly skews hardware performance metrics and invalidates test accuracy. This article explains how simultaneous video playback consumes critical GPU, CPU, and memory resources, triggers display refresh rate conflicts, and degrades frame times, ultimately leading to lower average frame rates and worse 1% lows than the hardware would achieve in an isolated test environment.
GPU Resource Consumption
Modern graphics cards have dedicated media engines to handle video decoding separately from the main 3D rendering cores. However, playing a video still consumes core GPU resources. The media player or web browser requires Video RAM (VRAM) and a small percentage of the 3D engine to render the application interface and output the display signal.
In VRAM-heavy benchmarks, this extra memory allocation can push the graphics card over its capacity, forcing it to use slower system RAM and causing severe stuttering. Furthermore, keeping a second display active with moving video prevents the GPU from allocating 100% of its power budget to the game, slightly reducing boost clock speeds.
CPU and System Memory Overhead
Playing a video—especially through a web browser—requires substantial CPU and RAM resources. The processor must manage network data, decode audio streams, and handle background browser threads.
In CPU-bound gaming benchmarks, or when testing at 1080p resolution, these stolen CPU cycles directly reduce the average frames per second (FPS). More importantly, background CPU interruptions disrupt the timing of frames being sent to the GPU. This heavily degrades 1% and 0.1% low frame rates, which are the metrics used to measure micro-stuttering and overall smoothness.
Refresh Rate Desynchronization
Many dual-monitor setups combine displays with different specifications, such as a 144Hz primary gaming monitor and a 60Hz secondary monitor. When a video plays on the 60Hz screen, the operating system's display manager must render and synchronize two different refresh rates simultaneously.
Even on modern operating systems, this mixed-refresh-rate scenario can cause frame pacing issues, increased input latency, or forced V-Sync anomalies on the primary display. If the game is benchmarked in borderless windowed mode rather than exclusive fullscreen, this synchronization issue is significantly worse.
Hardware Acceleration Conflicts
Browsers and media players use hardware acceleration by default to offload tasks to the GPU. When a benchmark pushes a GPU to 99% utilization, the graphics driver must constantly switch contexts between rendering the benchmark and rendering the video. This introduces frame latency.
While the drop in average FPS might only be between 2% and 5%, the resulting spikes in frame times will ruin the consistency of the benchmark data. Turning off hardware acceleration in the browser does not fix the problem; it simply shifts the entire video decoding workload onto the CPU, creating a processor bottleneck instead.
Benchmarking Best Practices
Hardware benchmarking requires a controlled, repeatable environment to produce valid data. Because video bitrates, streaming buffers, and browser memory usage fluctuate constantly, playing a video introduces an unscientific variable into the test. Unless the specific goal of the benchmark is to measure real-world multitasking performance, the secondary monitor should be turned off and all background applications closed before running any hardware tests.