Timers seemingly getting stuck.

[MarkSimon]

Hi,
I'm afraid this might sound a little vague, but bare with me.
On my application, I have a scrolling marquee constantly scrolling text from right to left. The timer is set to a resolution of 18ms. I've noticed, especially when the application is running in "debug" mode (in visual studio), that the timer scrolling the text will seem to occasionally pause - and not continue again until I move the mouse, click a mouse button or press a keyboard button. It's like the timer gets stuck until some user input occurs.

I've noticed this can occur if a slot called by a widget signal perhaps takes a little too long - unless I decouple it using a short single shot timer of say 5ms. For instance, my app has a tree navigation pane on the left. When the selection changes, I use "onItemSelectionChanged" slot to find the selected item, and change the right hand pane accordingly (usually creating a new frame, populating it with widgets, etc.). Sometimes when I click a tree item, and I'm very careful not to move the mouse afterwards, the scrolling text pauses - until I move the mouse.

It's a large fairly complex app, so there could be another issue causing this, but I've done a lot of testing and it does seem to come down to the timer pausing until some input occurs. I'm not sure if any other timers in the app are pausing as none are as visually obvious as the scrolling text.

Does this ring any bells with anyone? It's not a big problem as I can work round it; plus when I compile the app optimised in release mode the problem does not seem to occur - I'm thinking probably because everything is running faster.

Could it be a problem with fast timers? Perhaps if the timer is set to 18ms and an operation ties up the main event loop for longer than 18ms, it causes the timer to sometimes get stuck? It does seem a little easier to repeat if I speed that timer up.

This is on Windows, using Qt 4.6. I've not tested it on any other platform as I do not yet have the build scripts sorted out.

Thanks.

Mark.

[MarkSimon]

Further info:
It does definitely seem related to the speed of the scrolling text timer. Also after adding some extra debug information, the pause seems to occur when changing views (as described above) and the old view had a timer, and that timer was destroyed.
Here is the trace output from my app:

ScrollingText::TIMER: 1339 <=== output for every timer call
ScrollingText::TIMER: 1340
ScrollingText::TIMER: 1341
LocationTabView: init <s> (11792) <== new right pane view being initialised
LocationView: <0> (11796)
LocationView: <1> (11796)
LocationView: <2> (11796)
Timer[n6] <AnalogSensorViewFlickerTimer> constructed (097454C8)
LocationView: <3> (11801)
LocationTabView: currentChanged <s> (11810)
LocationTabView: currentChanged <e> (11810)
LocationTabView: init <e> (11823)
ScrollingText::TIMER: 1342 <== Scrolling text timer manages to get another "tick" in here
~LocationView: <0> (11926) <== OLD view being destroyed as a result of a call to "deleteLater"
Timer[n6] <AnalogSensorViewFlickerTimer> destroyed (097C5F48)

^=== pauses here, just when a timer from the previous view is being destroyed.. coincidence?

I move mouse, it all carries on as normal..

ScrollingText::TIMER: 1343
ScrollingText::TIMER: 1344
ScrollingText::TIMER: 1345

etc..

Also - if I slow the scrolling text right down to say 500ms, the problem does not occur. 5ms seems to be a good speed at which to reproduce the problem.

I'll see if I can write some code to easily reproduce the problem. The actual project is currently around 40K+ lines (and proprietry) so obviously I can't post that!

Thanks,

Mark.
--

[squidge]

Timers < 20ms or so use cpu-hungry MMTimers, whilst timers > 20ms or so will use regular timers. Unless you require the accuracy of MM Timers, it's recommended to use the regular ones by using a higher timer value.