J8 vs macOS paint calls drama/advice

[t0m]

@thecargocult

Interestingly, turning off JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS seems to have fixed the issue for one user, who even reports the app feels snappier now.

BREAKING_CHANGES.md

`juce7` technical preview branch

I don’t think there’s a benchmark we could provide that would be useful to people. I’ve said this a few times in this thread, but it doesn’t look the message is being communicated very well: Please stop referring to it as a ‘Metal’ renderer. The ‘async’ mode is probably also rendering to a Metal layer (it’s just opaque to us behind the macOS/iOS API). The only benefit to JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS is to avoid Apple automatically consolidating redraw regions that coul…

From JUCE 7 I would only recommend using JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS in the specific case where macOS or iOS is erroneously marking more area than necessary as needing to redraw. In that specific case then enabling this flag allows your software to do less drawing, but the raw drawing speed is much slower. If this would be a benefit to you is highly dependent on your specific GUI.

@thecargocult

We had also used a specific combination of setPaintingIsUnclipped() and setOpaque() on different components. IIRC there were big performance improvements with some of these choices in very heavy layouts, and some of these gains were contrary to the suggestions in the comments in the juce code.

We’re currently working on changing how setPaintingIsUnclipped and setOpaque work to make them both much more intuitive and effective.