It indeed would be a waste if that would be the case, but JUCE does not redraw the static parts too.
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.
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.
Can you expand on this?
You’ve previously wrote
if it does work it might hurt performance on anything other than Big Sur.
- 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
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.
@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.