Sonoma Rendering Issue

Mac OS Sonoma 14.0
M1 Pro
XCode 15
JUCE 7.0.7

I’ve observed some rendering issue with the last version of MacOS.
Screenshot 2023-09-25 at 16.22.48

Steps to reproduce:

  • Create a xcode project using the projucer and the “HelloWorldDemo” example
  • put #define USE_COREGRAPHICS_RENDERING 0 in juce_graphics.h
  • add the following following code in the HelloWorldDemo ctor (the confirmationButton is a simple TextButton):
        quitButton.onClick = [&]
            confirmationButton.addToDesktop(0, getWindowHandle());
            confirmationButton.setBounds (getWidth() / 2 , getHeight() / 2, 100, 100);
  • run the application and clic on the quitButton

It seems the default behaviour of attached windows changed on MacOS Sonoma:

The workaround is quite easy, just put [view setClipsToBounds: true]; in the NSViewComponentPeer ctor but it’s not available on older versions of xcode (like xcode 13).
Another workaround is to set the opaque flag to false confirmationButton.setOpaque(false);

As usual, Apple like to change default behaviour without telling anyone :sweat_smile:

1 Like

Ever since upgrading to Sonoma I’m getting severe hangs (2+ second UI lock ups) when resizing the window that is using complex paths (CustomMatPlot plotting a waveform). It was resizing incredibly smoothly before I upgraded:




Weirdly, it seems to render a lot more smoothly with the waveform that seems to have less path overlap over itself (the 808 waveform, which is closer to how smoothly it rendered before). It has nothing to do with the length of the sound (the short hihat is very laggy as well).

I’m able to get somewhat smoother performance by reducing the line thickness to 0.1f on the hihat:


1 Like

I am also getting this issue with jumpy resize across all plugins I have that use JUCE using MacOS Sonoma. It’s not just my own plugins but everyone else’s too. Can be replicated most easily by doing a slow resize

I can confirm that one of my plugin also has a rendering issue on macOS Sonoma (Intel chip). The level meter is not able to render smoothly (should be 60Hz, trigger by a Timer) and eats much more GPU than before (source code is available here, a little mess :smiling_face_with_tear:).

  • this plugin renders smoothly on Win10 virtual machine on the same MacBook Pro
  • another plugin which renders an oscilloscope (by OpenGL) still works properly
1 Like

Thank you for all the code examples. We’ll take a look shortly.

1 Like

Does the slow resizing issue affect only plug-ins that are built on Sonoma (and then run there), or all plug-ins that are executed in Sonoma exhibit this behaviour, regardless of the OS version they have been built with?

1 Like

I just pulled up my email to run the .vst3 version of a plugin I sent out before I upgraded to Sonoma and can confirm that pre-Sonoma builds are also laggy

Nice! Wholeheartedly appreciate your efforts!

Edit: Interestingly, I made the plugin full screen (At that size it takes like 5-6 seconds to repaint two graphs on an M2 Mac), and deleted it so it saves the previous size. Then, opened it again (making sure that previous memory was cleared), and it pops open almost instantly, even at a huge size. It only seems to be slow on resize

1 Like

Thanks for reporting this issue.

The initially-reported issue (new default value for clipsToBounds) is now fixed on develop:

We’re investigating the resizing problems, and will update this thread once we have more information to share.


Fantastic! Much appreciated! :smiley:

Just to confirm that its only a resize issue and not an issue with path drawing overall: One of the plugins I have that is broken by this issue has warp markers that cause the waveform plot to redraw when the markers are moved. I can move the markers perfectly smoothly and the plot redraws nicely at 60 FPS. Same for this sample loader component, I can click through samples really fast and it redraws the plot basically instantly.

Only on plugin resize does it lock up heavily

We managed to reproduce the resizing issue with little modification to an empty Xcode template, and without relying on JUCE.

At this point this may be something that Apple has to look into and fix, so we filed a ticket with them explaining the issue. I’ll update the thread when we know more.


Thanks so much for investigating and for the update! Hopefully they address this

We’ve received some feedback from Apple, confirming that this is a bug in the OS.


For what it’s worth, turning on setBufferedToImage also causes path drawing to slow down. Turns out it’s not just on resize