TextEditor has lots of timers spinning every 380 ms

This an observation on the really useful TextEditor control code.
I have the latest source (1.19).
So I’m using the Timer class in a project of mine to update a control (it is a VU meter).
It ran fine until I put a bunch of TextEditor controls on the form.
Now I notice that the VU meter I’m updating is starting to hiccup every 1/3 of a second or so.
So while stepping into the JUCE libray code that handles callbacks and i notice that there a lot of callback objects.
All of these callback objects turn out my newly added TextEditors and all of them go off at 380 milliseconds.
So why are a bunch of TextEditors getting callbacks every 380ms?
After examining the TextEditor source I see they all have timers spinning to update their carets.
But only one TextEditor at a time needs a timer for updating a caret, the one in focus would be best!

TextEditor::moveCaret() is called when I call TextEditor::setText(),
which starts a timer that just spins even if it has no visible caret.
So in effect TextEditor::moveCaret(newCaretPos) is starting a timer upon initialization (when I set the default text of the control).
This Timer never gets deactivated if I don’t touch anything on the form.
So now I got a bunch of timers spinning when I only need the one for the one TextEditor in focus (if any).

For the time being I removed StartTimer in this moveCaret, I don’t to need it right now.
This solves my hiccup problem because I don’t have bunches of timers going off now.

void TextEditor::moveCaret (int newCaretPos)
if (newCaretPos < 0)
newCaretPos = 0;
else if (newCaretPos > getTotalNumChars())
newCaretPos = getTotalNumChars();

if (newCaretPos != getCaretPosition())
    caretFlashState = true;
    caretPosition = newCaretPos;

------> //textHolder->startTimer (flashSpeedIntervalMs); // my change to the JUCE library

I normally wouldn’t care that some extra timers are spinning but they all hit at once and
give a noticable hiccup to my otherwise smooth looking VU control.

Any thoughts on this guys?
Or am I missing something?
I just wanted to post something about this, it could prove to be a source of frustration for someone else using the Timer.

either way this is a really cool library, it is fun to program in.

sounds a bit funny.

those timers should not degrade performance I would have thought. it’s not like they have a massive callback.

i think juce uses win32 Timers and if so they are almost negligible if you have a short callback.

dunno mate. half asleep. just woke up.

a few texteditors bringing performance down? don’t sound right.

even Tracktion runs vaguely smoothly and it must have a lot of crap going on as well as meters.

jules will be along shortly…

Thanks - I’ll check that out and it probably could be optimised a bit, though I’m very surprised that it’d actually cause a noticable effect - the timers should barely use any cpu at all. Maybe the text editor’s repainting unnecessarily or something. I’ll have a look.

Are you in debug mode? If you are try compiling and testing it in release. Graphics are much faster in release mode.

I was indeed in debug mode.
When I get to work tomorrow I’ll try release.
Still that many TextEditors in debug mode should be fine.

My basic test was to remove all the TextEditor controls from the form. That seemed to fix the problem.
Then removing that startTimer did the trick.
I’ve been using my mod for about a week now.
But hey I could be going about it totally wrong, I’ll mess with at it again tomorrow.

I think the problem was probably that each timer callback needs its own message to be sent, so when a bunch of timers triggered at the same time, these took a long time to be sent, getting in the way of other timers that needed to happen. So not a CPU problem, just a scheduling glitch.

I’ve had a go now at redesigning the timer class in a way that triggers multiple callbacks more efficiently, which should hopefully smooth this sort of thing out.

cool, thanks for looking into it!