I have a “progress bar” component that needs to redraw fairly often, which can cause performance issues when it forces its parent to redraw as well. I’m calling setOpaque(true) on it, but I’m seeing what appears to be an OS-specific problem. On Windows, this behaves as expected: the component redraws and its parent does not. On OS X, I’m still seeing the parent redraw, regardless of whether the component is opaque or not. Does anyone know why this happens, and is there anything I can do to work around it?
Long discussion here which is probably the same thing:
I am having exactly the same issue and I spend a lot of time to read and understand
all the posts here in the forum to a certain level.
I also spoke to a software developer who uses QT on Mac and he could NOT
confirm to have same issue in QT. To me it means that there must be a way
of getting around this Core Graphics limitation. Otherwise all applications
for Mac would suffer.
I am by far not an expert because programming is not my profession and
my target it to have my application running as audio plugin on both, Mac and PC.
I neither have the time to learn Cocoa nor the knowledge to dig into this. I just want to
have a solution.
Therefore, if there is someone who has a work around ready and would
like to share it, please do. I even consider paying some money if the
work around is closed source. I don’t pay any amount but I am sure there
are some more people here who would spend some money to get the problem
solved and to get back to the point they’ve started from – having fun in
programming funny plugins for both, PC and Mac.
I really like juce as it is easy and transparent and having to stop my project
just before the end because of this repaint issue would be a personal ground zero
I don’t think there is a workaround. When the OS asks us to repaint a complex region, it’s AFAIK impossible to find out accurately whether a particular rectangle within that region is occluded or not.
It’s a subtle problem that’ll only arise in situations where you have multiple separate rectangles being repainted at the same time with some space between them, and even then you’ll only notice a problem if you have another component which overlaps the bounding rectangle of that complex region, and which has a heavy repainting load which you need to avoid when possible. Just because your Qt-using friend hasn’t seen this doesn’t mean they’ve solved it. If you asked a random juce user whether they’ve seen this, I’m sure 99% of them would also have never had a problem with it either.
You could of course use the software renderer instead - this is only an issue with CoreGraphics.
Well, I have deactivated CoreGraphics and this brought the CPU load down by around 30%
to around 90%. So there is still an issue and it still seems to be related to repainting.
My plugin has a size of 1200 x 800 pixels where I have a list box in the top right corner
and a status bar at the bottom of the plugin. The list box has a scroll bar and 16 items
where each item has a Midi input meter. If a Midi control message arrives either via Midi input or
from host, the meter in the list box, corresponding to the incoming Midi channel
goes active and only its small meter area gets redrawn. Simultaneously the status bar at the
bottom shows the incoming message type translated into text. If the list box row containing the active
meter is visible, than I have a CPU load of around 90%. If I then scroll the list box to make the
particular row invisible, the CPU usage drops down to 50%. To me it seems to still repaint
the area between the list box and the status bar thought there is noting to repaint.
All painting is down by timers.
I’ve played with setBufferedToImage(true), setOpaque(true) and actually all suggestions from the forum
but no luck
So I think I have to profile or found somebody to help me profiling it. I’ve never done it before
and probably won’t be able to read the results properly.
Should I see the issue when I turn on the repaint debugging flag?
Would CachedComponentImage help here?
If you’ve not profiled it yet, then that should absolutely be the first thing you try. Never try to guess about performance problems, measure them!