Windows 11 Issue with openGL

[Gazolike]

Hi,
I’ve got some issues with JUCE plugin on reaper windows 11, on a mixed openGL/software rendering plugin.

Windows 11 Pro 21h2
Intel i7-12700k
64GB RAM
Nvidia 1060GTX
Reaper v6.67

Note that it was reproduced with integrated GPU and dedicated GPU. Not reproductible on Windows 10.

When there is a mix between openGL and CPU rendering in a window, the drawing become very laggy in certain situation.
The basic scenario is just load the plugin, drag a simple knob, and it may lag dragging knobs.
Another scenario is to run an automation on a parameter bound to a knob, making the knob repaint, then resize the REAPER window (not the plugin one, the window with tracks) to a small size, the knob redraw will start to lag. You can also reproduce by dragging the REAPER window to be partly (at least half of it) out of screen.
I think it’s more on the OS side but I wanted to report it here too.
Some other considerations:

• If you launch certain other application (for example vsthost) while the knob is lagging, the other application will lag too.
• If you use spy++ (the msvc windowing tool located in “Common7\Tools” folder of VS installation) and you inspect messages of the PLUGIN window, you won’t have lag anymore (I suppose this is due to something like missing refresh on the plugin window, which spy++ may force)
• While you resize the REAPER window, you won’t have lags, only when the resize is finished.
• the OpenGL drawing area is always fluid, only the software rendering part lags

If you want to reproduce, I’ve modified the GainPlugin example from JUCE repository, just clone the repo and launch the build commands:

cmake . -B cmake-build -DJUCE_BUILD_EXAMPLES=ON -DJUCE_BUILD_EXTRAS=ON
cmake --build cmake-build --target GainPlugin_All

The repo to reproduce: https://github.com/Gazolik/JUCE/tree/Win11_Issue

Thanks,
May be Windows 11 update was not the best thing to do

[gabrielegiuseppini]

Oh, I am SO glad someone else has found this bug, I thought I was crazy. I’ve posted it on a couple of Microsoft forums (e.g. Redirecting and Window refreshes are randomly skipped on Windows 11 when SwapBuffers() has just been called (regression from Win 7, 8, and 10) - Microsoft Q&A), so far no one has reached out to me. This bug is seriously impacting the bottom line of mixed OpenGL/software applications.

To me it seems Windows is skipping redraws of non-OpenGL windows when an OpenGL SwapBuffers takes place regularly in a separate thread. But also in my case, there are things that make this disappear - for example, starting another windows timer refreshing a window every 15ms, or using spy++ as you mention.

What can we do to raise awareness of this issue to Microsoft?

[chikashimiyama]

I have experienced exactly the same problem recently on our VST plugin with OpenGL Visualizer and a few knobs beneath it. By manually reducing the refresh rate to 30, the GUI lag problem was improved a bit but it didn’t solve the problem fundamentally. Is there any workaround for this problem?

[flavi0]

I tested your GainPlugin on Linux and I’m also experiencing problems with a sluggish UI and missing redraws. This includes the “Options” popup window provided by JUCE. This is for the Standalone version of your plugin, for some reason Bitwig on Linux has failed to load the VST3 version so far.

This sounds like it could be the same issue that I posted here

OpenGL context with continuous repaint causes UI freeze

Dear JUCErs, using the recent develop branch I found that when I set my OpenGL context to continuously redraw at the screen refresh rate using setContinuousRepainting (true), it can cause other UI elements to freeze for a long time, sometimes in the order of 5 or more seconds. Using older versions of JUCE this did not cause a problem. My application does not draw anything yet, I simply derived from Component and OpenGLRenderer and override newOpenGLContextCreated, renderOpenGL and openGLContex…

The application also uses mixed 2D / GL accelerated rendering.

In that thread I posted a minimal example project to reproduce the problem as well. It is also built via CMake but assumes that JUCE has been deployed somewhere (using the INSTALL target or make install respectively). CMake has to be told where to find the JUCE installation by using the JUCE_DIR environment variable to point to the .cmake files (in lib/cmake/JUCE-X.Y.Z relative to the installation root).

It would be great if someone could test this on Windows 11 and report whether the same issue occurs. I only have Windows 10 to test here, where the issue was not present. Maybe it is not Linux- or Win11-specific after all but a more general issue.

Best,
Patric