Calling repaint() in intervals without needing to use Timer


#1

In my app there’s a waveform display that shows the waveform of the MP3 that is being played. It goes without mentioning that the graphical update should never be interrupted and should be truly constant.

At the moment I use a Timer that calls repaint() every 20ms or so to update the waveform display. But the problem is that, since Timer messages are sent through the message queue, the waveform display starts to stop for a little time as soon as I (for instance) do some action with the mouse in my Treeview or some other scrolling components, because this will generate a lot of messages in the message queue that will be processed before my Timer callback.

How should I do it to keep the Waveform display updating at fixed intervals with no interruptions?


#2

Well there’s no magic trick that’ll sort it out! Repainting always has to happen in the message thread, so all you can do is to be more careful about not blocking it unnecessarily.


#3

You could use paintEntireComponent(Graphics& context) from your own thread if you have somewhere to blit.

I am using that call with an app that renders an OpenGL component outside of the message thread, in which some JUCE components are rendered as textures. I create a context from an Image that I am using as buffer, then that context is passed to paintEntireComponent in my custom JUCE components. Finally, the image (which now has the component drawn in it) is rendered as a texture in the GL component.

I am not sure that this would work with a regular Juce component as a final destination, since you have no control over when those get rendered. However, if your waveform doesn’t need any interactivity and you are willing to dip your toe into GL, this strategy works, and it will be much smoother than the standard JUCE rendering path. I can post code if you are interested.

Jules, maybe JUCE should have something like BufferStrategy in Java? It would be nice to have more control over rendering without resorting to GL.

c.


#4

BufferStrategy is a new one to me - what does it let you do?


#5

It basically allows you to take control of the graphics rendering. You can specify how the window is buffered (double - triple - N buffering, ring buffering, etc.) and when it is rendered.

The kicker for anyone that develops something that requires fast drawing is that rendering is decoupled from the repaint() mechanism, therefore from the messaging thread (if done right). Instead, it is up to the programmer to flip the buffer, and this can be done as fast as possible, or at the proper time.

Here is the documentation for BufferStrategy, which includes a usage example:
http://java.sun.com/javase/6/docs/api/java/awt/image/BufferStrategy.html

In Java, creating a BufferStrategy from a window is generally accompanied by “setIgnoreRepaint(true)” so that the component will only render when the programmer flips the buffer, and not when the system determines that a paint() call is necessary.

I haven’t looked at how JUCE renders (and I am no expert in these matters), but just having a the ability to manually flip the buffer would be nice.

c.


#6

Hello, I’m new to this forum. I’ve been looking through posts on OpenGL rendering and refresh rates in JUCE, and I’m trying to get a sense for whether JUCE is suitable for a demanding 3D animation application. I need the application to be able to animate a complex 3D model at consistently good refresh rate while maintaining responsiveness to user events. I’m having trouble understanding from the various posts what the real limitations are, partly because I haven’t studied the API as yet. Could someone please advise me, as I like so far what I’ve heard about JUCE but don’t want to run into trouble with the primary function of my software (animation). Many thanks.
Michael Berger


#7

Sure, right on, I am very interested in it :slight_smile:


#8

The problem is, in my app there are many scrolltexts, and each time I move the slider in a TableListBox, the scrolltexts stop scrolling and this looks VERY unprofessional.

Is there maybe some trick I could use to still have fluid scrolltexts?