JUCE_ENABLE_REPAINT_DEBUGGING is a bit more complicated than that because CoreGraphics keeps its own complex clipping region. This means that it may present the combined clip rect to JUCE, causing it to call all of the paint methods down to the the CoreGraphics calls, however CoreGraphics will only draw the actual pixels it knows internally are dirty. If you put DBG statements in component paint calls that lie in between you may well still see them being printed out.
Using JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS aims to reduce the number of paint calls simply caught up in the clipping rect but it then has the disadvantage of having to traverse the whole Component hierarchy etc. multiple times. This also has a cost associated with it.
This essentially means that you have to weigh up how much work is done in your own paint methods compared to how long CoreGraphics takes to perform the drawing routines. Minimising work done in paint routines that will never result in things actually getting drawn is one way to improve on this (e.g. use a
GlyphArrangement rather than lots of
drawText calls to essentially cache all the path calculations).
As always though, be sure to profile to avoid making your drawing code needlessly complex for very little benefit.