Complex GUI

I’m new to the forum, and equally new to Juce.
We’re looking into porting an existing plug-in family from another library to Juce, but there are a few things I itch to learn first.

Our “problem” is that our plug-ins have very complex GUI, which now contains layers of “windows / panels / widgets” to represent different aspects. Also, the entire GUI can be wiped and recreated entirely differently again and again. We use a lot of graphics for these components.

Thirdly, we currently use modal windows (equally complex) which I wish to get rid of for obvious reasons. A good replacement strategy would be to simply overlay the components of the Modal window onto the main window and get rid of the modal-ness. Somehow…

I don’t doubt that you could create such a GUI, but I’m imagining many layers of graphics and “windows”. My question is: Does Juce handle panels and widgets itself or does it use OS provided functionality for this? How hard can you press the plug-in window until it breaks?

It all depends on if the layered windows you use are opaque (non-transparent) or transparent, how big they are, if they need complex drawing algorithms, or are just blitted images. If they are opaque, what’s below doesn’t need to be repainted, so you already gain some CPU.

All in all, I would say that JUCE, for me, has always been sufficiently good enough for GUI’s in most ways. The only real problem that can arise is when you want to make animations, they have to be timer-based, and timers are in the message queue. What happens is that if something else in the main thread needs to finish first, your animation will be stuck for some time. This is maybe one of the only things that I don’t like about JUCE, because I think that today, in 2011, animations should be smooth.

If you use graphics (images) for rendering the components, it’s especially fast, because it’s just a matter of copy’n’pasting.
All in all, you can literally have thousands of Components on the screen and as long as they don’t need to repaint all at the same time, it’s all well. Only the parts of the screen that need to be repainted are repainted. If I was you, I’d quickly make some tests. And to start checking out the JUCE Demo, which shows some animations including fps.

Thanks zamrate,
I’m doing tests now and it looks pretty good. By the end of the day I hope to learn more about the worst case, having layers of layers of components on (for example ) an OSX 10.4 Mac G4 laptop running out of system resources.

I believe it’s rather easy to write a GUI platform such as that in Juce where the window & component management is situated in the user domain, as opposed to using the local OS’ own window management. I imagine it’s easier to run out of “system resources” than just “RAM”. So basically I’m asking: how much is Juce relying on the local OS for window & GUI component management. (I should have said so yesterday :wink:

Thanks guys!


Sounds like a good number to me!

In other words - if I cram the plug-in with tons of tons of stuff and test in on a super duper development machine, it will basically run everywhere assuming the RAM on the machine will hold it?

That’s how ALL the OSes and toolkits handle repainting/animation. It’s the only sensible way to do it - it’d be an unmanageable threading/locking nightmare if you had a bunch of components whose paint() methods were being called by one thread while their their event callbacks were happening on another. The only alternative is to use a completely different model, like openGL.

Perhaps if you’re finding the repainting glitchy, it’s because you’re doing complex tasks on your event thread, and should be moving THOSE tasks to another thread, rather than assuming it’s the repainting that should be done by a different thread.

Absolutely. (Nobody runs out of RAM these days, do they…? I can’t imagine how many millions of UI components it’d take to fill a GB of memory!)

Very comforting. One last question: I believe that the window given to the plug-in by the host is managed by the “Component” class, which I understand is a window surface you can place widgets in. - Can you layer additional Components inside Components? I need to move around subsets of widgets across the screen at will.

Thanks for all your helpful answers!

It’d be a pretty lousy UI toolkit if it didn’t do basic stuff like that!

Well I had these problems, and I certainly was using a thread for everything that would take more than a 1/10 second. In my case, if the user moved the scrollbar of a (big) TableListBox, all animations would slow down from let’s say 50fps to 10fps, making the app look unprofessional. This was not me being a lousy programmer, but JUCE taking too much time to paint the TableListBox (Fonts take a lot of time to paint, I realized), which slowed down everything in the message thread!

The truth is: if you need absolutely smooth animations, that are smooth under all circumstances, you can’t even rely on JUCE’s OpenGLComponent, because to animate it, you will again need a Timer which is only as smooth as what happens in the message thread. I remember trying a different approach using a Thread as a Timer together with the OpenGLComponent, but it locked, the app froze, because of the way OpenGLComponent interacts with the rest in JUCE. In the end, I wrote my own OpenGLComponentEx class, which indeed works with a special high-priority Timer-Thread, and I have my OpenGL animations running smoothly under any circumstances. But I can tell you, I did sweat to get my final result!

It’d be a pretty lousy UI toolkit if it didn’t do basic stuff like that![/quote]
I suppose. It didn’t take much time to modify Hello World to verify that. I’m pretty much committed at this point. I love your stuff!

Thanks for your insights zamrate. I don’t think we will rely so much on animation, other than VU meters and alike. I know I love a beautiful GUI as much as anyone, but I’m amazed everyday how much graphics it takes to do audio processing. But it sells. It sells.

I think if you don’t have a screen full of level meters, it’s ok.

I have the closest plugin I know to a screen full of level meters: .

Animating all the dials at 30Hz is OK on recent machines, a bit too tough for older ones (~1GHz Core 2 Duo or similar). Playing a movie over the plugin’s whole window would be no problem for these old machines, so I’m sure there are inefficiencies in the Juce framework that could be improved. My own audio code has so far been in more need of optimizing though.

When I have had specific performance issues in the past, Jules has been very open to ideas and almost supernaturally quick to respond.

Cool madronalabs. And good looking.

At this point we haven’t committed officially but it’s looking good. The plug-in family that will be ported is ReValver: or at the very least the upcoming versions of it. The vision is to expand the complexity in some ends and shrink it in others. The current version(s) have had difficulties with the usage of Modal windows, something I hate to begin with. ReValver Mk II and Mk III and Mk III.V is done in wxWidgets, which is “so-so” on Mac.