DaveH
October 12, 2024, 6:08pm
1
Hi, I’m getting an odd problem with Juce 8 compared to Juce 7.
I have a context in my PluginEditor with this in constructor:
openGLContext.setOpenGLVersionRequired(OpenGLContext::openGL3_2);
openGLContext.setRenderer(this);
openGLContext.attachTo(*this);
openGLContext.setSwapInterval(1);
openGLContext.setContinuousRepainting(true);
newOpenGLContextCreated is not being called at all until I manually resize the plug-in.
Calling resized in code doesn’t help either.
Does anyone know what’s going on here in Juce 8?Preformatted text
DaveH
October 12, 2024, 9:22pm
3
Here is a simple project that uses OpenGL
Created with Projucer 8.02
I’ve tested it with Windows 10 FL Studio, Ableton live, and Cubase Elements 10
I just created a new project and added the OpenGL module, then set up the simple OpenGL stuff in the code. Is there something I’m missing?..
OpeneGL_Test_DH.zip (23.8 KB)
The function newOpenGLContextCreated() never gets called, does anyone know why?
I think it was called in FL Studio, but not on a saved project!
psyDSP
October 13, 2024, 3:17am
4
This issue seems similar to one I reported previously. It originated from commit 555b667 but has been fixed as of commit f5f758c in the develop branch.
It seems that this commit causes OpenGL rendering issues on Windows, specifically when using a custom OpenGLRenderer component within certain DAWs. Instead of the expected output, the screen displays only black. This behavior wasn’t present before this commit.
Below are images showing the issue in Studio One 6 on Windows 11. This example simply fills the background with a solid grey color using OpenGLHelpers::clear.
Latest JUCE 8 Develop:
[juce-8-non-working]
JUCE 8 Develop prior to commit …
DaveH
October 13, 2024, 10:58am
5
I didn’t see your previous problem with it, thanks for tracking down the commit, I’ll try going back. I wonder if it’s an Async issue, and a wait is needed somewhere in the init process? It’s odd that I can compile an old OpenGL project and it runs fine. Just not a new one like the project I posted above.
It’s not calling newOpenGLContextCreated at all.
reuk
October 14, 2024, 10:24am
6
Just to confirm, I can reproduce this behaviour in a plugin project on Windows 11, but it is fixed on the develop branch by this commit:
committed 06:50PM - 30 Sep 24 UTC
This partially reverts commit 555b667d228439e36cbcd8f820090c1882ce3d76.
Using C… omponentPeer::isShowing instead of ComponentPeer::isMinimised
inside Component::isShowing can cause problems when displaying OpenGL
components.
Specifically, OpenGL components use a ComponentMovementWatcher to
determine when they should be attached/detached from the parent window.
The ComponentMovementWatcher updates whenever a component visibility
change event is emitted, which happens in two cases:
- Component::setVisible is called on the OpenGL component or an ancestor
- ComponentPeer::handleMovedOrResized is called in response to a
minimisation state change
When handling either of these events, the ComponentMovementWatcher will
call Component::isShowing to determine whether or not the component is
really showing.
The problem is that the result of ComponentPeer::isShowing may change
independently of changes to the Component visiblity state or
ComponentPeer minimisation state, so the ComponentPeerWatcher might not
notify its listeners when a component is really shown/hidden.
One potential workaround would be for the ComponentPeer to send
notifications when the showing state of the window changes, so that the
ComponentMovementWatcher can forward those notifications. The main
problem with this approach is that on Windows, the window doesn't seem
to receive a message on hide/show, and it's not clear whether there
exists some other approach to detect a hide/show event.
If there were some event we could listen for on Windows, then we could
call Component::sendVisibilityChangeMessage in response to this event
and things would *likely* work at that point, but this may still have
unintended side-effect. As a result, I think the best approach to
restore the old behaviour is to revert the change to
Component::isShowing. The implementations of ComponentPeer::isShowing
have been left in place so that users can do still query the real
visibility state of native windows if necessary.
1 Like
DaveH
October 14, 2024, 11:30am
7
Brilliant! That worked great.
Thanks for checking it out.
I can use ‘develop’ on a new project.
I guess things have moved around quite a lot for such an old piece of code to fail.