I just updated my juce lib to the latest via GIT. But the new version seems to have a very slow graphics rendering engine. I tried the tests in the new graphics demo. It shows it took over 100ms to draw a RGB image and it also drives my CPU fan. I wonder what have changed in graphics engine from about a month ago? Is there a option that I can avoid pure software rendering?
Thanks.
The new graphics code is maybe very slightly slower than the old stuff for some types of operation, and is faster for others. But it definitely isn’t “very low”, so I feel rather wronged by the title of this post!
On my Mac, the RGB demo renders in about 10ms, compared to about 8ms for the CoreGraphics native renderer - which I think is pretty damned good for code that doesn’t use any SSE optimisation. So either you’re using a old Pentium II, or running it in debug mode or something strange…
Yes, the Mac build is normal, about 10ms. But on Windows it is about 100ms and CPU is 100% used. I will show you some screenshots later.
It’s exactly the same code on both platforms!
The old version used to have some pragmas to turn on compiler optimisation just for the graphics code, even in a debug build. That’s no longer there, but a release build will still be at least as fast as the mac.
I didn’t say I didn’t believe you, and don’t understand why you think it was useful to post a screenshot!
Like I said several times, you’re probably testing a debug build. Try a release build. It’ll be fine.
[quote=“jules”]I didn’t say I didn’t believe you, and don’t understand why you think it was useful to post a screenshot!
Like I said several times, you’re probably testing a debug build. Try a release build. It’ll be fine.[/quote]
I tried the release from the GIT tip. It’s better than debug, but still slow comparing to the old version. When I drag a slider in my app, the CPU goes up to 30%. But the juce demo is fine. I wonder what could be wrong with my app.
That makes two of us. I have been having problems as well but would like to come up with a smaller test app to reproduce the problem. Jules recommended that I do some profiling of my app to find out what is using up the CPU the most - I am still to do this but I haven’t had to profile an app before so I need to get info about which tools to use etc. I will post anything I get.
If you can come up with a bit of simple test code that shows the problem, I’d be happy to try it.
Visual C++ profiling, urgh. One first sees there are menu options for profile guided optimization in the 2005 Express, Standard, and Professional versions; then one discovers they don’t necessarily work. One needs the $500 version to enable Profile Guided Optimization, and the $2500 version for full profiling.
I found a simple free profiler called “Very Sleepy” for Windows here:
http://www.codersnotes.com/sleepy
It’s now thread aware, and it helped me get the typical CPU utilization down from 30% to 4% in short order!
According to task amanger I’m still getting occasional peaks to 18%, and peaks are very difficult to isolate in a profiler, because they average over sample ranges of course. I don’t have any reason to believe the expensive commercial Visual C++ profilters would be any better at finding peaks. Is there an easy way to trigger a breakpoint in Juce if the CPU goes over a particular level?
The anser to my question is, there is a method getCpuUsage() for reporting CPU usage in audio callbacks in AudioDeviceManager. I guess it could be adapted for other needs.
CPU of 4% with peaks of 18% for an app that’s busy doing stuff and redrawing its UI sounds pretty reasonable to me.
You can use the PerformanceCounter class for measuring specific bits of code, but remember the golden rule of optimisation: “Don’t do it unless you really have to!”
I found out the reason. I have a big custom component which paint it’s own content. And a slider value changes will call repaint of my component which makes CPU full.
However, the interesting thing is even after I commented out everything in the paint function, it still caused a high CPU usage (about 20%). While In old Juce, if there is nothing in paint, same continues repaint calling just makes about 5% CPU usage. It looks like there are some overheads upon repaint in new Juce windows graphics engine.
All of these are in release build and windows xp.
Hi,
That remind me a discussion I had with Jules regarding repaint …
I also had CPU overhead since using post Core Graphics juce (on the mac obviously).
What happening is that when my vumeter is repainting, it is triggering the main UI paint () method.
And redrawing the whole UI every 30ms instead of just the vumeter make ( of course !) things much slower…
Now I found that making some component opaque, optimizing the redraw method (using more drawImageAt than the other method ) etc… helped to get workable result.
also, some things are faster now with coreGraphics (on mac), so at the end, after some tweaks, it’s not rocket speed, but I’m close to the same performance than with the ol’ Juce 
Salvator
I created a test app but that wouldn’t reproduce my issue. It could be my application. I have used Very Sleepy and Perfmon for profiling. I wonder if there is way of determining which function is taking long. From very sleepy, I can tell that this has to be something with the messaging thread. There seems to be a function called UnwindUpVec that takes a lot of time (90%) when there is constant mouse movement. Any ideas?
Finally got around using very sleepy better. Please have a look at the attached profile. If anyone has better leads re how to analyse this I would appreciate it. I am going to have a look on the sleepy website.
I created a test app but that wouldn’t reproduce my issue. It could be my application. I have used Very Sleepy and Perfmon for profiling. I wonder if there is way of determining which function is taking long. From very sleepy, I can tell that this has to be something with the messaging thread. There seems to be a function called UnwindUpVec that takes a lot of time (90%) when there is constant mouse movement. Any ideas?[/quote]
Hi mate,
This “UnwindUpVec” is a function called in memcpy.asm, so let’s say a very low level function. But having a look at your attached log, I could see that it’s actually called by
MidiBuffer::Iterator::Iterator which is, itself, called by
edgeTable::operator= which is … weird . But maybe that’s gonna ring a bell to you ?
Well, although the stack is probably a bit garbled, the edgetable copying is what you’d expect to see if it’s doing a lot of drawing. If it’s using 90% then you must be rendering a lot of small, possibly tall, thin objects…