`juce7` technical preview branch

[t0m]

@sudara

I’m interested in any other hard datapoints. Would be fun to cook up a little benchmarking app to help people make informed choices for JUCE drawing.

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:

@t0m

The fact that we have Core Graphics rendering into a Metal layer is an implementation detail. We are not expecting any performance benefit from using a Metal layer over the default layer provided automatically by Core Graphics, other than the fact that we can provide a mechanism where individual dirty rects are redrawn individually.

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 could be rendered separately. Therefore the performance of the JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS is very highly dependent upon the extent to which Apple consolidates redraw regions. It will be extremely different for different GUIs. There are cases, in real plug-ins, where it has dropped the CPU load from 85% to 5%.

You should try enabling the flag if you think you might benefit from avoiding having Apple consolidate your drawing regions, and you need to measure the effect in your own software.