(Edit) – This was a feature request but was later discovered to be impossible.
Here are some steps for better debugging:
- The JUCE debug repaint IS showing you the dirty regions the UI has decided to update for your app, it is NOT showing you the full rectangle the OS told you to draw.
- You can see the rectangle only by using Quartz Debug Tool which you can get from apple developer downloads
Between the two you can see a) the rectangle which is repainting in your app, anything inside or touching this rectangle repaints. b) anything which flashes with repaint debugging on actually was redisplayed to the the screen.
If your UI code is fast and you’re getting inexplicable frame drops, it COULD be from the repaint throttling happening in the NSComponentPeer – although it’s not clear why apple is dropping your dirty regions from repainting, and there’s no real transparency to figure it (that I’ve found)
More info on this below
–
Hey! I’ve been migrating from OpenGL to CoreGraphics because of rendering issues on M1 which appear to be more solid with CoreGraphics – the issue is that I’m still having some lag in certain view of my UI.
Upon further investigation I’m finding that CoreGraphics is passing a massive clip region to top component regardless of my “dirty” component bounds and regions, and it appears to be due to how rectangles are merged etc etc – I know this has been discussed at length – but it would be great if there was some way to debug the true clip region that goes to the OS on our views, this way we could much more easily debug the true repaint strategy that’s occurring on the OS level.
Even with a great repaint strategy – the way everything gets merged seems to just fail at the highest layer, and it doesn’t appear: JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS does anything to improve the massive clip region which is produced.
I think I need to also just a better understanding on how the view stuff happens, is there a reason we group all the clips into a single handlePaint on the highest level – it seems it would be much faster to just have more paint calls with smaller regions?