New Graphics performance

Jules, I’m wondering if your comment here includes the AudioThumbnail class. We recently updated our tip snapshot. We had previously been building against a version of the tip from September of last year. After updating to a newer version of the tip our UI performance in Debug builds in Windows became incredibly slow. We have a component that displays a waveform, and we use AudioThumbnail::drawChannel( ) to draw it. I see that drawChannel() uses Graphics::drawLine( ) to render the waveform slices. I disabled the waveform drawing, and the UI performance was indeed back to the responsiveness that we had before updating the tip. Obviously, just disabling waveform drawing altogether is not exactly a bulletproof demonstration that AudioThumbnail drawing is the bottleneck, but I wanted to know if it could be related to your comment above.

Yes, the audio thumbnail will indeed be an achilles heel of the new code.

I might have a look at this today, actually, and see if there’s something I can do to optimise it…

just FYI
I’ve implemented something like AudioThumbnail by myself, but used the following trick:
I’ve created an Image, and drawing new received sample data to the rignt border of an image.
After that I use moveImageSection() to mothe all tthe image to the left by one pixel.

Unfortunately, on mac this routine (moveImageSection) produces CPU usage spikes (my core2duo macbook pro is more or less ok with that, but newer pac pro based on nehalems are going crazy if I do such a thing in rtas plugin ), so I have to drop yjis kind of drawing, but if you not using it in RTAS plugin, it is ok.

Quite a sneaky trick!

If you’re going in at that level, by far the fastest way to draw it would be to use Image::BitmapData to get the raw data, and blend the pixel data yourself.

Some more info on the subject.

Jules, please don’t get me wrong, this is just an info for you. I’m not trying to start the war here.

I have a plugin. Pretty simple UI, just 8 knobs (filmstrip).
Knobs are big (something like 100x100 pixels)

RTAS version of plugin produces CPU load spikes in PT HD on mac pro/ mac osx systems (not everywhere, but a lot of responses, and mostly on newer nehalems).
I’ve tried all the things out with almost null result.

Yesterday, I’ve downloaded JUCE version 1.50. UI became much more responsive (almost like on windows machines)
Spikes in PT are gone.

I have to add - plugin does not have a huge UI, just a bitmap skin with filmstrip knobs.

I understand that all this doesn’t have any matter for the most part of JUCE users, but I feel like it would be better to put all this on the forum in case if someone else will have similar problems.

PS I tried to look into the JUCE renderer code, but it is not a simple code, so no help from me here, can’t point to the problem, sorry.

Hope this will help someone.

As I’ve mentioned many times now, I’m going to optimise the software renderer for vertical lines, as those are drawn more slowly in the new code, and quite a few people are moaning about that.

If you’re using a Mac, all the rendering is now done with CoreGraphics, so any speed problems there are Apple’s fault, not mine. But when I’ve optimised the software renderer, you might see better performance by using that instead of the CoreGraphics renderer. (In fact it’s worth trying that anyway, as it might improve things for you).

Chaps, I’ve checked in an update that boosts the vertical line drawing performance hugely - please have a go and let me know how you get on!

Perhaps not as useful now. Towards the end of July, I decided to try using the latest tip of juce. The graphics issues that I had previously are gone now.