When I call repaint on my spinner [setOpaque(true)] its parent is also repainted.
Any idea why?
My repaint knowledge isn’t that hot: Should the clip region in the Graphics object match the size of the component being repainted? My component has bounces {6, 4, 16, 16} and the clip area of the Graphics object is {5, 4, 18, 16} !
Ok - if i set my 4k monitor to 100% (instead of 125%) scaling and reboot I get the expected behaviour.
We are running on JUCE 4 on this app still because of some upgrade complications 
Maybe there’s a fix for this already…?
Can’t find one searching the commits though …
It’s likely to be a rounding thing, I’m not sure it’s possible to only invalidate the child rect if there’s a non-integer scale factor applied…
I’d say.
This is a pretty expensive problem though. And non-integer scaling is a thing.
I guess you could add a 1px border to your spinner and only repaint inside that?
Not exactly clean…
And we have other cases where I bet this is a problem. Probably explains why my dialog windows repaint constantly even though the progress bar is setOpaque!
Presumably Graphics::fillAll() is my main issue and this already restricts itself to repainting the clip region only. The status bar was more of a problem because of a logo we had on there that was expensive to paint.
On the upside - I know a lot more about repaints now.
If this is unfixable it should be added to the setOpaque documentation as it was an hours work and a couple of reboots to be sure what was happening.
what @dave96 has written, is also my approach, because of the non-integer transformation the borders contains mixed pixel between the parent and the child region.
repaint(1, 1, getWidth()-2,getHeight()-2);
…can fix this, but of cause you need to care that the animation does not goes beyond the borders.
But anyway when you begin to have more than 2 animated objects, alle the objects between this objects also repainted, because the os or juce merge the two repaint regions.
Another experimental approach could be, to add these opaque components directly to the desktop (like the openGL component), which are following the position relative to the window, so the OS-window manager composes the regions without any repainting involved.
Isn’t that just an OSX thing?
There is JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS on macOS but I’ve yet to see any definitive proof as to whether it’s better or not. My gut feeling is that it vastly depends on your UI, its layout and the repaint frequency of each object.
Not sure about other OSes but I wouldn’t rule it out. Even if they don’t do that now, there’s nothing to say it won’t happen in the future…
I’m going to print out my UI in future and stick it to the screen.
