Apparent serious JUCE painting issue in Big Sur

Now that we’re deep into January, does the JUCE team intend to address this issue? Currently the only way to get around the Big Sur drawing inefficiency is with the hack posted above, and even then drawing is not efficient on macOS if there are multiple rectangles being invalidated.

It would be nice to know that the JUCE team is working on fixing these issues for their next release. We’d be happy to help test any beta improvements.

1 Like

Yes, we’re looking at this, but we have not found a better solution than setting contentsFormat. We’ll very likely be committing that change shortly.

3 Likes

Can you expand on this?

You’ve previously wrote

if it does work it might hurt performance on anything other than Big Sur.

Some questions:

  • Does this hurt performance on other systems?
  • Is the problem on Big Sur a different problem than the one on Mojave

I’ve tested on a few different machines and have not seen any evidence of a performance hit. Some Catalina and earlier machines even rendered very slightly quicker after this change, but benchmarking GUI performance rigorously is notoriously difficult. We’ll keep our eyes on the forum.

This fixes an issue where the clipping region returned is always the whole window (despite what JUCE_ENABLE_REPAINT_DEBUGGING would suggest). It does not restore the the usefulness of JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS as getRectsBeingDrawn will still return 1 in all cases.

1 Like

This fix does, however, suggest that it might be possible to fix an iOS issue that sounds very similar, but I’ve been unable to reproduce the problem on iOS.

1 Like

@midiculous @PixelPacker Can either of you provide an example of similar behaviour on iOS?

@t0m Please refer back to our long PM exchange with code snippets and examples.

That exchange was about a macOS rendering issue with different characteristics, but in the thread I linked a couple of posts ago you mention an iOS problem:

We noticed that this method does not work in ios, so for our apps the entire view is being repainted over and over when moving any widget.

t0m, it appears the viewWillDraw() fix causes a crash in macOS 10.9 and possibly other early OSes. We’re going to try to work around this, but you may want to make sure the production JUCE code accounts for this.

Dan

Do you see crashes on the current tip of the develop branch?

The version of viewWillDraw() in the development branch looks promising. We’ll test it and report back.

Is the JUCE team still working on a fix for the dirty rectangle problem? We can make our GUI pretty efficient with a combination of this fix and the JUCE_COREGRAPHICS_DRAW_ASYNC flag, but it would still be considerably more efficient if the macOS versions weren’t repainting so much extra all the time.

Thanks!
Dan

I can confirm that the dev branch code, which checks for Big Sur before modifying anything, solves the problem.

Dan

1 Like

Ouch these fixes were definitely needed. Such a big difference on performance now on Big Sur. Massive drop in CPU usage, we have quite some animating sliders in our ui and they were causing full repaints. Very important to keep track of this behaviour. Probably hard to build a unit test for this but these are those hidden issues where you could spend days and days figuring out what you did wrong. Happy to see this fix.

Why not enabling the fix also for older OSX > 10.9?

t0m,

At this point, with the Big Sur workaround, buffering of our controls, and use of the undocumented JUCE_COREGRAPHICS_DRAW_ASYNC flag, we have GUI performance on the macOS roughly equivalent to the performance on Windows, which is a huge relief. However, I still have to believe that performance would benefit greatly from fixing the ability to paint only the dirty rects, as more than one dirty rect appears to cause the entire application to redraw. Are there plans for this to be improved in the next release of JUCE?

I’ve not found a way to get the CoreGraphics backend to stop consolidating regions. We are currently looking at different rendering approaches, but it’s unlikely that anything will be ready by JUCE 6.1.

3 Likes

Apologies for asking a question that might be answered already; we’ve seen the complete UI redraw issue on both macOS and iOS. Does it help to go back and use an older iOS or macOS SDK to resolve this temporarily, or is this issue caused by the OS itself and rolling back Xcode or SDKs won’t help? Anyone tried this?

No.
unlike Microsoft, with Apple most SDK is dynamically linked to the current macOS
(there are ways to set different frameworks/dyld mostly during development due to secuirty limitation)

Only workaround for getting responsive UI is caching ( setBufferedToImage) and using OpenGL renderer.

3 Likes

ok, thanks!