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