Clarification about screen refresh needed


#1

Hi,

I just need a little clarification. Let’s say that animated things happen on the screen at a quite fast rate (much faster than needed . ex : vu metters)
for performance reasons, let’s say I decide to limit myself to 20 frames/second.

  • Should I call the graphic methods (like drawRect, setTopLeftPosition and stuff …) as often as I want, but call only repaint, once every 50ms
    OR
  • Should I call those graphic methods once every 50ms
    OR
  • Something else

Which one is better suited with juce ?


#2

no one ? :frowning:


#3

Your question doesn’t make a lot of sense. You can only draw things in your paint method, and the only way you can choose how often that happens is by calling repaint. So just call repaint as often as you need.


#4

Ok I’ve been thinking a bit more about this.

If you use a slider as a VU-metre for example. You have 2 possible approaches :

  1. Everytime AudioProcessor::ProcessBlock is called , you calculate an RMS value and set the slider’s value accordingly. Of course you won’t do that from the audio thread but you can use void AsyncUpdater::triggerAsyncUpdate( )and in handleAsyncUpdate(), you call Slider::setValue

  2. Everytime AudioProcessor::ProcessBlock is called , you calculate an RMS value and set an (atomic) variable to this value. Then in another thread, that you call, let’s say 25 times/sec, you call Slider::setValue

Below I assume that Slider::setValue is calling repaint() (that’s what the code seems to do)

In the first case , triggerAsyncUpdate() will push a message to the system message queue to call handleAsyncUpdate(), and then handleAsyncUpdate() will push another message for repaint. So that’s 2 messages by repaint, and we don’t know how often they’re called.

In the second case, you send a repaint message 25 times/sec

So there’s a difference in terms of message thread congestion, system load etc, isn’t it ?
Which approach do you think it’s best ?


#5

Am I saying complete bull**** ? :smiley:


#6

Option 2 sounds better.


#7

I use option #1, its the only approach that scales. Option #2 in theory works but can be too frequent on a lower power system, and too infrequent on a high power system.