JUCE 7 repainting bug?!

Hey jucy people…

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 :sweat_smile: :sweat_smile:

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)

1 Like

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,

1 Like

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.

Is this relevant/useful? ( Driving OpenGL Rendering Loops)
Driving Technical Q&A QA1385: Driving OpenGL Rendering Loops

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??

1 Like

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

What is it about resizing using the concertina bar that blocks the cvdisplaylink, that resizing the whole window doesnt block? @reuk ?

I’d recommend using Parallels to keep all past versions of macOS available for testing on the same machine.



1 Like

It happens on my Monterey M1


Bumping this up as this bug fixing is crucial to the release of an app which we were hoping to build in Juce. :no_mouth: :no_mouth: :no_mouth:

This is on my backlog, but I’ve got some other (also OpenGL-related) issues to look at first.

hey there, hoping for updates!!

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.

amazing thanks :v: :v: