This is not something i coded wrong, i took the latest JUCE tip and built the JuceDemo, on Windows rotating the entire widgets demo takes about 8% when sliding it very fast, on the mac the cpu usage takes about 80%, sliding one slider on the demo page takes 0-1% on the mac it can spike up to 30%, it’s pure JuceDemo and default build settings from the projects.
Could someone confirm this and maybe let me know what i might be doing wrong.
On the side note, theese are 2 different computers, but the MAC one has a Core2Quad and 6gigs of ram, the pc is a dual xeon quad and 12gigs of ram.
I was ofcourse testing with the Release builds, and not attached to any debugger.
I also tried that with both the COREGRAHPICS renderer constant set to 1 and 0 and no difference. Also the first page of the juce demo runs at about 13-14% cpu.
Well if you have shadowing turned on in the ComponentPeer, it will slow the Windows redraw rate a bit. Try turning off the window drop shadow and re-run your test.
Rotating the widgets demo is probably the hardest bit of number-crunching you could make it do! And sure, if you drag the slider, at every mouse move it’ll attempt to redraw the UI - so if a redraw takes longer than the interval between two mouse-moves, it’s inevitable that it’ll saturate at least one of your cores! That’s not a bug or a surprise in any way.
And comparing the windows and mac CPU levels is completely meaningless. It’ll depend entirely on the heuristics that the OS uses to decide how often to send a repaint message, which are not comparable at all.
No, that won’t make any difference at all. The only time you’ll have a performance impact is when the window is being resized. Or if your window is non-opaque and you’re drawing into it.
comapring windows/mac sure makes no sense i just wanted to present the difference.
however sliding one slider in the demo and having this much CPU used is ok ? it’s hard to believe, if i write a plugin that does no audio processing (just midi) and add 10 sliders and automate them all from the host i will eat all the CPU resources. I’m sure that’s not right, moving one slider shouldn’t cause this much cpu usage or should it ?
It doesn’t actually matter whether the CPU hits 100% when animating the UI - if there are spare CPU cycles that aren’t being used by higher-priority tasks (e.g. audio threads and other realtime stuff), then it’s perfectly sensible for the UI to make use of that spare capacity to animate the display more smoothly. Dragging a slider will tell the UI to repaint maybe 50 times per second, and the UI is doing its best to keep up with that, which involves a hell of a lot of work!
this isn’t actualy a question from me but from the users of the plugin i write, that’s why i’m asking (i was pretty sure that this is how it has to be and should be just wanted to make sure).
thank you for the answer and i will assume this behavior as normal.
I remember in 1.52 that component peer drop shadowing was implementing using HWND transparency, which was more expensive to blit to the screen, did something change?
That’s why it made me sigh! CPU meters should be banned! I guess they give a vaguely useful overview for some kinds of program, but for any kind of non-continuous, bursty task - like any kind of UI - it’s doesn’t tell you any meaningful information.
Yes, but the window itself isn’t transparent, just the shadow windows around it, so drawing into the window itself isn’t affected.
Switching off core graphics did help here as the parent component its paint method doesnt get called
anymore using Jules software renderer while dragging a slider that is set to setOpaque(true).
It maybe doesn’t matter, but it’s a very bad sign! Moving a few sliders, even steadily animating them at 100Hz should not take more than 1-2% CPU today (think of a screen-sized Mixer full of level-meters: It must be smoothly and quickly animated although there is a lot of repainting going on! And it should not eat more than 10% of the computers’ CPU in my eyes). Games with millions of polygons repaint at speeds over 60Hz, and so should optimally do apps too!
Generally, I tackle the problem by only using drawImageAt() and fillRect() functions, which are fast. All other JUCE drawing functions are slow, or have become much (1.5-4x) slower (but better quality) since JUCE146. If you draw your sliders with Path’s etc… each time, expect there to be a lot of CPU usage.
