[Qt-interest] QTimer on Windows in Unreliable for Small (16ms - 30ms) Delays

[Josiah Bryan]

Jeffrey Brendecke wrote:
> Could disk access be tying up the system?

Shouldn't be - nothing disk intensive at all while running - only Qt 
Creator and the app open.

> I don't think the QTimer can be considered reliable. It will try to time out 
> when it can, but there is no guarantee that it will. The documentation 
> mentions discarding timeouts.

I've checked for discarded timeouts - they always arrive, just arrive 
later than desired. (Check using a simple integer counter, nothing fancy.)

> Maybe you could consider something like the following involving a couple of 
> threads. Using more than one thread at a time comes with its own set of 
> problems, so there are many things to consider before trying it out.
> 
> * Put the rendering in one thread: This reads the info from the disk and 
> generates a small queue of frames to be shown. For fluid replay, it would be 
> necessary to keep this queue from getting empty at all time.

Good idea - you mean, like having the decoder & renderer in the same 
thread? I'll try that...

> 
> * Use a reliable timer that does not discard ticks. I don't know what this 
> would be.

Me neither - thats why I tried checking out windows native timers, but I 
couldn't get any of that code to compile - I tried for a good hour or so 
- no luck.

> * In the main thread, on each time out, pull a rendered frame from the queue 
> and display it. If the ticks are not getting swallowed due to whatever 
> external constraints, then it seems the rendering would need to give, 
> stopping rendering and going on to the next frame if it did not finish in 
> time. Maybe some sort of interlacing could result in at least the frame 
> getting covered from top to bottom, though not on every line.

Sounds interesting - not sure how to implement that - care to elaborate 
any more?

> It seems this should work, but the implementation would be very difficult and 
> involve a good understanding of the control mechanisms necessary in 
> coordinating the threads.
> 
> Then again, there may be something already out there. I have not used Phonon. 
> I had trouble getting it to compile with its many dependencies when it first 
> came out and have not tried it since. If you are clear as to why you are not 
> using Phonon, maybe someone could help you out with it.

Same here - on linux, I spent a long time trying to compile phonon - 
never did have any getting it to run. 
(http://www.mybryanlife.com/blog/josiah/2389). On windows, I've tried 
multiple times to compile it with the "Qt command prompt" - e.g. going 
into c:\qt\qt...\ and doing configure, then mingw32-make - each set of 
attempts has resulted in different problems. I can try to recreate if 
anyone cares, but bottom line is that I found it *way* too difficult to 
get phonon working - after about a week of on-again, off-again working 
on it in my personal time, i gave up. Anybody have any binaries or 
how-to's would be welcome.

For now, I've limited the minimum delay to 32ms - that seems to be about 
the smallest amount windows handles without doing abnormally-long 
delays. Yes, literally - 31ms causes anomalies, but 32ms - none - that 
I've seen yet. The lower below 30ms, the more frequent the anomalies. By 
the time I hit 16ms (the target, 60 fps) - the anomalies hit about once 
every 20 - 30 frames - just randomly taking > 1000ms to fire, instead of 
the desired goal of the requested 16ms.


-=-=-=-=-=-=-=-=-=-=-=-=-
Josiah Bryan
Productive Concepts, Inc.
jbryan at pciint.com
(765) 964-6009, ext. 224