BUG: Resizing TableListBox with attached OpenGLContext very jerky in macOS 10.14

General JUCE discussion
1

I updated my development machine to Mojave last week and I’m now noticing that resizing the window containing a TableListBox causes very jumpy columns in the TableListBox. I verified that this does not happen and everything resizes smoothly on 10.11-10.13 (my app’s deployment targets).

I also verified that it works normally when the OpenGLContext is not attached to the container component. However then things are not very fluid.

I uploaded a video of what it looks like here:

And a minimal sample project here:

Would be great to know what could cause this and how to fix it.

Thanks and best regards,

Flo

2

I’ve found in the past that Mac’s need:-

 openGLContext.setSwapInterval(0);

And then use my own millisecond timer to wait for 20 milliseconds in renderOpenGL(), just to get it to behave correctly. Sorry for lack of detail.
*edit * BTW your video doesn’t work.

3

Thanks Dave, but I guess that’s not it in this case.
Everything is working as expected on systems < 10.14.
Also, it doesn’t look like this is an update problem.

Regarding the video. I only pasted a link to the video on Dropbox and the forum made this player view automatically. It also doesn’t work for me.
But you can right-click it and then do “Open Video in New Tab” or something similar.

Any other ideas?

4

Is your issue just with resizing? Yeah, it can look messy and on some plug-ins it can take forever to update properly, but it settles down OK. It does it with my plugs but it always works OK when I stop moving it.

5

No offense but “it works ok” is not my quality demand :wink:
It feels really clunky now while everything was smooth before.

My app is not an audio plugin but a standalone Mac app.
The window shows lists with 15-20 columns and sometimes several 100 lines and the users will resize the windows regularly.

6

The problem seems to be related to the warnings like [NSView frame] must be used from main thread etc. given by the Main Thread Checker in Xcode when OpenGLContext is attached. I have it with ListBox too.

It looks like OpenGLContext is calling some methods in juce_mac_NSViewComponentPeer.mm from a separate thread when they should be called async instead?

7

@MBO you should probably start another (forum)thread with that.
People overwhelmingly voted for the renderer to be updated last time Roli gave us an update vote.
The more complex your graphics become, the more you’ll see it actually drawing it all, I’ve found quite it messy especially if you have OpenGL mixed with normal Juce components.
See the demo of ‘Voltage’ by Cherry Audio for an example of resizing in Juce with a complex plugin:-
https://cherryaudio.com/voltage-modular/download

8

What happens if you compile against the 10.13 SDK (or whatever version you were previously using to compile)?

1 Like
9

Hey t0m,

thanks for the suggestion!
The 10.13 SDK from the link doesn’t seem to work due to some missing symlinks but linking against the 10.12 SDK is enough for everything to render smoothly again.

What does that mean now? That 10.14 changed something when rendering windows that might cause the standard JUCE GL resizer to not behave like it should be?

Thanks for your insight!

1 Like
10

Yep. There were multiple rendering-related changes in 10.14 that caused behaviour changes. We’ll investigate this one.

2 Likes
11

Thank you! Much appreciated!

12

I faced the same problem on macOS 10.15.
I am wondering if it is because renderOpenGL() is called between resized() and paint() of its attached component as follows,

  • resizing the window
    • resized() called
    • renderOpenGL() called
    • paint() called
    • renderOpenGL() called

I assume that after renderOpenGL() is called the first time, NSOpenGLView displays the previous sight of the component with the new window size for very short time, which results in the jerky drawing.
Perhaps renderOpenGL() should run after both resized() and paint()?

13

Thanks for picking this up!
With the advent of Catalina I will need to move my build server to 10.15 in order to get notarization working easily so this just came back to the table within the last days.

I hope to have time to try around with it soon but I’d appreciate any insight from the JUCE team especially @t0m who has already responded previously.

Is this something you have on the radar @t0m?

Thanks in advance!

14

You can notarize using Xcode 10.1 on macOS 10.13.6. And then you can install an older OSX SDK (for instance 10.11) in Xcode. That way you’re sure to avoid issues related to 10.14.

15

Thanks for the comment!
Yeah, I know it works on 10.13 as well.

I have however ordered a new Mac Mini as my old 2011 model just wasn’t up for the task anymore.
Rolling back to 10.13 is not straight forward from what I read and having to use 10.13 for TableListBoxes to work properly using OpenGL is also not ideal.

16

@TaloKay do you have a working solution? If so, do you mind sharing it?

17

I tried around with this again esp. @t0m’s suggestion about linking to older SDKs.
Happy to report that I’m successfully building everything on 10.15 linking against the 10.12 SDK.
Rob Napier’s script linked in the article from t0m’s link is especially great at applying the symlinks when updating Xcode: https://gist.github.com/rnapier/3370649

The table list bug is gone. The performance may need some fine-tuning, but that’s likely my code and not JUCE related.

18

I am sorry but I haven’t got any good solutions.
However, I found that this problem happened only when changing the size of the Component in which the OpenGLContext is attached.
So if I apply the OpenGLContext to all child components bind to the parent component (with OpenGLContext) and as far as I do not change the size of child components, it won’t make any jerky effect.
But I know it is not really relevant to your case of TableListBox.

Do you know the timing renderOpenGL() is called within 10.12SDK?
I am wondering if its timing is one of the reasons causing the effect as mentioned in my last submission.