OK i have been working on these meters for quite some time and for the most part I’m happy with them. I have 36 big meters on screen all redrawing at 50ms each I’m using bliting and have a smart repaint method in place so it only repaints whats changed. so i have them inside of a fader component that includes some info boxes a panner and a volume fader. now if i pull everything off the screen i can get all metters running smoothly with about 0 - 10% cpu usage. but as soon as i add a Slider next to the meters my CPU goes up to about 20 - 50%. I’ve been mucking around with setOpaque and setBufferedToImage with different results with the meters themselves but no mater what even if i put a default Juce slider with no custom graphics i see this huge boost in CPU usage. I’ve had sure that the two components do not clip each other and operate in there own space with in the parent component. So anyone out there have any suggestions? this problem is making my forehead flat from banging it up against the wall please help.
do you get any speedup if you assign the ShinyLookAndFeel to the slider? the standard LookAndFeel applies a shadow effect to the slider component, and it would be interesting to hear if this is effecting your CPU usage in any way.
You will probably have to make the content component opaque, repaint it yourself, and make the meters and sliders opaque and repaint them too, filling in their background with a rendered image copy of what they overlay (or just filling in with a color if that’s all that’s needed).
I had just a dozen or so meters and sliders that were bringing my cpu down to its knees until I handled ALL the repaints myself rather than letting the default component repaint member get called. This is because components are non-opaque by default and if one component overlays another, when it’s marked dirty, the component underneath gets redrawn. If any other components clip that second component, they get redrawn too.
You’ll be able to see what’s getting redrawn by enabling #define JUCE_ENABLE_REPAINT_DEBUGGING 1 in juce_Config.h.
Hi Thanks for your responses
I have been monitoring the redraws with the JUCE_ENABLE_REPAINT_DEBUGGING option enabled. it appears that all that gets marked for redraw is the changes in the meter images themselves. I also tried to use the shinylookandfeel slider instead and that took about %15 more
cpu then the default juce slider did. the component that contains all these widgets is set to Opaque but this component is also a few layers deep in the app with in a Tab component and another content component that i use to create multiple channel strips. All this seems to work fine until i put a slider object next to be meters. The slider and meters aren’t touching and it doesn’t look that the slider is getting redraw when the meter does. one thing i did notice is when I’m watching the invalidated rectangles the debug mode leaves I’m not seeing the sides of them only the tops and bottoms of the rectangles.
There might be something that I could optimise here, but very hard to know what it is without having the code to play with. If there was some way you could send me an example app that does this I’d be happy to take a look at it.