Is there a reason this include was removed from juce_gui_basics.cpp"? #include “native/juce_CGMetalLayerRenderer_mac.h”`
It breaks compiling with JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS=1.
However, I’m unsure as to if I should be enabling this at all now, the BREAKING_CHANGES file is basically a 
Removing that include was accidental - we’ll put it back.
Whether JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS is beneficial is entirely dependent on the form of your GUI, so you will need to test.
If Apple is consolidating individual dirty rectangles across large areas of your GUI then it will probably be beneficial. An arrangement where you have meters top left and bottom right may be constantly invalidating the whole of your GUI, and this flag forces only the actual dirty rects to be redrawn. In real-life situations like this I have seen CPU usage drop from 85% to 5%.
If no dirty regions are being regularly consolidated then JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS will result in worse GUI rendering performance.
Yeah, it’s difficult to tell with such a variable UI…
Rendering with multiple paint calls still draws async though doesn’t it? It just adds the potential overhead of running the juce::paint routines multiple times when one would have possibly done if I still understand it correctly.
Unfortunately you lose all of the performance gains of async rendering with this flag, so the baseline performance regression can be significant.
Support for JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS has been restored for the direct2d branch.
Matt
