Weird phenomenon here, since I moved to JUCE 7 one of my components repainting got messed up: the component is composed of various children of which one is an OpenGLRenderer… what basically happens is that on resize of the parent component only the OpenGL one gets actually repainted/resized, while its siblings get stuck and repainted/resized after 1/2 seconds… while debugging I’ve noticed that the parent resized() function gets stuck and triggered twice before returning… (it gets stuck when the openGLcomponent.setBounds() is called)
I have a define on cMake that allows me to switch back and forth between JUCE 6 and 7 and this problem only appears on JUCE 7.
The error appears on two different OSX versions (Mojave and Monterey).
I tested this on Monterey 12.5.1 and High Sierra 10.13.6 (Intel) using the DemoRunner. I don’t have a Mojave machine available for testing. After opening the OpenGLDemo.h demo, I’m still able to drag the corners of the window to resize it without any freezing or other issues. The window is a little bit slow to resize, but nowhere near a second.
Do you see the same problem in any of the JUCE example projects? If so, please provide detailed steps so that we can reproduce the problem. Otherwise, if the problem is only present in your application, please provide some minimal example code that demonstrates the problem.
Hey, sorry for the late reply, I have been busy on other bugs chasing for the app I’m working on
I hope in the next couple of days to provide you with a customized version of the OpenGLDemo.h where I can recreate the error - weirdly enough- though, the problem does not occur when trying to resize the whole app, but only when trying to resize it within the app (while resizing ConcertinaPanel, using ResizableBorderComponent etc.).
Hiya, as promised I’m back with an example of the issue, I also screen grabbed it in order to show a little video of the actual behaviour, as you can see in the video - resizing the openGLCompoennt through the concertina does not work properly while resizing the whole window presents no issues- (might be a clue for you guys).
here’s the video:
here’s the public repo with the code:
I’ve tried to make the repo as simple as possible: (I’ve been fighting with git as I rushed through it so i didn’t ignore anything)
Im working with @tonytormio on this.
If its useful, its seems to be something to do with the opengl resize or repaint blocking the component repaint. Component resize is getting called during the drag, but its not repainting. It is possibly to do with the new Metal Renderer repaint controller combining the OpenGL repaint controller.
Thanks for you help,
marc
More clues for you:
I found that NSViewcomponentPeer:SetNeedsDisplayRectangles is being called continuously by the CVDisplayLink callback… EXCEPT for during the concertina resizer drag, when the calls are NOT happening.
I tried the develop branch and the problem is still there. The talk about WaitableEvent/CVDisplayLink etc would seem to be somewhere close to the problem… but Im just guessing.\
{EDIT} If I comment out the whole of openGLcontext::renderFrame, the issue goes away, but of course I dont see any GL graphics - so it would seem to me that the problem is in the lock code in the first half of this function, blocking the cvdisplayLink??
I just want to stress that when resizing the whole window, although the concertina gets resized as well (as a consequence of the mainwindow resizing), rendering works fine
I’ve put together a fix which seems to improve things in the test case that you provided, but it needs more testing to ensure that it hasn’t introduced new problems elsewhere. I’ll update this thread with any new developments.
We updated the juce repo and tested the fix, which makes things substantially better - but the problem is still there when the UI is particularly busy-.
To simulate the issue I’ve updated that repo that I used as an example (I’ve also implemented a layout stretchable manager, simulating a more similar architecture to our actual App), later in the afternoon I might be able to post a screen grab too.
Although we are moving in the right direction I’d like to speed up things a bit if possible - as we’re moving towards our first usability test cases but we still feel uncertain on release times because of this issue-, we’d like to set up a quick zoom call if possible.
I spent a day investigating this at the end of last week. I saw that occasionally, the OpenGL view would resize around one frame before the enclosing non-OpenGL view. I didn’t see any cases where the amount of lag was greater than a frame, and only then when the contents of the view were so expensive to draw that the resizing already stuttered badly. Additionally, I’m currently not sure how I would go about removing the frame of lag - I expect that it would take at least a few full days to make any progress on the issue.
At the moment, I feel that the severity of the issue is not high enough to justify the cost of the fix (we have many higher-severity issues to look at). As a workaround, you could consider using a single OpenGL context to draw your entire UI (i.e. attach an OpenGLContext to your top level Component), and/or optimise the painting in the rest of your UI so that it stutters less during resize.
Thanks very much for taking the time to check this out.
Would you mind just answering me one question so that I can have a hack at it myself: Where is the epicentre of the code that controls the sync between the opengl and juce rendering?
