I’m working on an app that has an OpenGL window which can be fullscreen on any available monitor. I’m doing this the standard way (hopefully) – adding a Component directly to the desktop, attaching an OpenGLContext, and moving the Component to various monitors with setBounds.
This is all working mostly fine. However, one very subtle thing I notice is that the OpenGL rendering is much less smooth when it’s on the secondary monitor. For example, if I just have an OpenGL quad (or whatever) moving back and forth across the screen, the movement is perfectly smooth on the primary monitor. But on the secondary monitor, it’s jerky and stutter-y. I’m not doing anything different at all between the two monitors – the only difference is the position of the window.
Anyone encountered this before? I’m not sure if this is a Juce issue or not, but I’d appreciate any suggestions or feedback.
And I just realized something else. The fullscreen aspect of it doesn’t matter. If I just have a normal (non-fullscreen) OpenGL window, and I drag it onto the secondary monitor, the same thing happens. Truly weird.
I would recommend delving deep into your graphics card’s OpenGL settings!
I have, in many versions of the NVIDIA driver over the years, seen the option of having the chip accelerating only the primary display, only the secondary display, or both.
The default setting I recall has been primary display only.
Depending on Windows version and graphics adapter driver version,
The primary screen is an important setting, but sometime, the initial window position who create the OpenGL context can have an incidence on what’s going on after.
(ie on which screen/adapter OpenGL context is created / vsync-ed)
Current nvidia GPU got a “surround” setting for 3 screens configuration. It can help only in this special case.
The basic check is to ensure all your screens have the same refresh rate.
(Ideal configuration was to have same monitor model / with same resolution.)
With multi adapter setup, other pitfalls can occur when SLI is activated or not.
(Multi GPU data upload, framelock, genlock…)
On window 7, Aero activation manage vertical synchronization between screens.
It perform OpenGL offscreen rendering on DirectX surface.
Who could also introduce frame drop stuttering.
Without Aero, according to DXGI Full Screen Exclusive Mode,
It’s seems that the best practice was to have a window per screen with shared context to avoid Vsync problems.
I think I figured it out actually. I was running my secondary monitor at 75Hz, and even though it supposedly supports that refresh rate, it didn’t like it. When I switched to 60Hz the problem mostly went away.
The stuttering must have come from the fact that the monitor was trying to “resample” 75Hz to 60Hz. Really quite odd.
