A question about repaint() and the Timer class

1

Hello everyone,

The documentation on Timer states the following:

The time interval isn't guaranteed to be precise to any more than maybe 10-20ms, and the intervals may end up being much longer than requested if the system is busy. Because the callbacks are made by the main message thread, anything that blocks the message queue for a period of time will also prevent any timers from running until it can carry on.

So assuming we are using a Timer to trigger repaint() on a given component, then that call will be later than desired, by some amount. Then by nature of the message thread, there will be another delay between repaint() and the actual execution of paint().

This poses an issue when drawing moving components. You will end up with different times between each individual paint(), or frame. I have personally noticed this, animations are a bit stuttered, caused by each frame being timed differently.

I understand why this happens, and that there isn’t anything that can be done, other than trying to have less activity on the message thread, so that there are fewer delays.

This leads me to my question… What are the alternatives? From what I can tell, it is to have the component inherit from OpenGLRenderer, and draw everything with shaders. Is this the only way to decouple your draw calls from the message thread, and eliminate the delay issues of the timer/repaint callbacks?

Thanks for reading, I hope everyone is keeping safe.

1 Like
2

Yes I believe this is the reliable solution, if you need smooth animation. However I’ve also achieved high frame rates just by using a timer and repaint. As long as you keep your message thread free from expensive calculations (i.e. do those in a background thread), using a timer is usually sufficient, unless you are doing complex animated graphics.

3 Likes
3

If you’re using a timer to call repaint then don’t forget to set setSwapInterval (0) because you do not want any hold ups.
I have found it much better to use this method as Cubase(mac) has a few problems with opengl plugins, it seems. On my 2 year old Mac, I go for about 30 fps for best compatibility with Cubase.

1 Like