PureBasic Forums - English

http://msdn.microsoft.com/en-us/library ... 85%29.aspx
CreateTimerQueueTimer() and related are supported on W2K+.
Does something similar exist on Linux and Mac? If so maybe a native PureBasic Timer Queue that basically wraps the API's on these platforms would be a nice feature?

I certainly would love that instead of having to roll my own. Obviously the issue here is Win9x which probably would need some extra code to emulate such a queue though.

sounds like my include:
Include - Trigger , signal forms with timer and more

EDIT: Or you can write it your self with Threads

What does this do that you cannot do with AddWindowTimer() ? (except that it doesn't use a window, but threads instead)

The timer queues (on windows at least) will change the OS timer period/precision automatically in needed. (they basically do something similar to timeBeginPeriod_() internally)
so you get down to ms precision, I believe window timers just use whatever timer precision the system happens to be in, and there is also the messaging overhead (vs this queue system).

This also takes advantage of the fact that the timer is run in a timer thread (or a new queue thread if you create that) so it takes advantage of threading/cores much better, I also believes the OS set a "timer" priority on the queue thread(s) as well, OS timer thread pools or whatever MS calls them.

I mean it's not like I can't do the API stuff myself, but I thought if Linux and Mac has similar then it might be worth looking into a bit more? as it would be solid crossplatform timer queue in that case.

What does this do that you cannot do with AddWindowTimer() ?

CreateTimerQueueTimer_() (which PureBasic currently doesn't import btw) allows you to reduce timer intervals to a true 1ms, which is necessary for smooth animations. That would be the main one for me.

netmaestro wrote:

What does this do that you cannot do with AddWindowTimer() ?

CreateTimerQueueTimer_() (which PureBasic currently doesn't import btw) allows you to reduce timer intervals to a true 1ms, which is necessary for smooth animations. That would be the main one for me.

But it does so using threads, which means you can't use DirectX in them (so no Sprite, Screen, etc). What is the use then for animation?

Hmm, darnit. You're right...

Hey freak I found this http://www.virtualdub.org/blog/pivot/entry.php?id=272
It's an interesting read. (the vdub dev really knows about timing APIs etc.)
He has a solution mentioned a bit later in the article.
I'm also looking into another API he's mentioned.

Problem is, the guy is wrong. timeGetTime_() is not 1ms accuracy and so his whole premise is thrown off. Consider this test: On my machine cc is reported as 10000 exactly after running 10 seconds. The accuracy is quite adequate despite what the fellow posits.

@freak: I wasn't even considering DX when I made the comment, there are lots of applications for smooth animation in gui's. An RSS feed scrolling across the bottom of your window, possibly tips of the day same location, and an aboutbox with a nice smooth scrolling presentation is very attractive. Custom wait/transfer animations, etc. With standard timing these all look choppy. These kinds of effects appeal to me as a gui programmer but I understand perfectly if others don't see the point.

Actually timeGetTime_() has 1ms precision, but it can only ever get close to that using timeBeginPeriod_() and even if set to 1ms you are not guaranteed constant 1ms timing, it may fluctuate from 0ms to 2ms.

And if I recall correctly, timeBeginPeriod_() will also affect Sleep_() and therefore also PureBasic's Delay().

@netmaestro
the vdub guy needed way more precision than 10 sec. He needed 1/60th or better.
He's also written about vsync/vblank/scanlines and more previously in his hunt for stable frame playback and syncing.

PS! Your browser (or certain plugins), your media player, etc. tend to mess with timeBeginPeriod_()
For example, playing a track in foobar2000 makes foobar2000 change timeBeginPeriod_() to 1ms, even when paused, only when stopped does it use timeEndPeriod_() and return system timings to normal. Windows Media Player uses 5ms.
So testing timings can be a pain if you forget, vdubs's dev even mentioned his media player messing up the testing, heh...

the vdub guy needed way more precision than 10 sec. He needed 1/60th or better

I don't think you understand my test... 10000 procedure calls in 10 seconds shows true 1ms granularity. Much better than 1/60.

netmaestro wrote:

the vdub guy needed way more precision than 10 sec. He needed 1/60th or better

I don't think you understand my test... 10000 procedure calls in 10 seconds shows true 1ms granularity. Much better than 1/60.

Btw: Here it's about 5100.

Doh! You are right. That's 1/1000 actually.

Maybe he didn't realize that the timer queues are also affected by timeBeginPeriod_() ? (I think they are, although the MSDN article doesn't seem to mention that?)

c4s wrote:

netmaestro wrote:

the vdub guy needed way more precision than 10 sec. He needed 1/60th or better

I don't think you understand my test... 10000 procedure calls in 10 seconds shows true 1ms granularity. Much better than 1/60.

Btw: Here it's about 5100.

I also get about 4960 (whether using debugging output or MessageRequesters). Using Win XP SP3 (x86)

Just a question: what do you need 1ms granularity for animations, when the human eye cannot see more than 25 updates per second anyway? (which would be 40ms each)

I am reluctant to implement something as simple as a timer through threads, because threads make everything magnitudes more complicated: You have synchronization issues, race conditions, deadlocks and a whole host of other non-deterministic behavior which make it very hard to write correct programs. Thread programming done right in a language like PB is hard, so requiring that somebody learn all this stuff just to get a timer working is ridiculous. (plus, there is the whole slowdown of compiling the program in thread safe mode)

Btw, i think smooth animations in GUI programs do not require threads. This is possible even in a single thread given that GUI programs do nothing but wait for input 99% of the time anyway.

I don't do animation so I cannot comment on that aspect but Windows does have high precision timers capable of sub-µSec resolution. I do have uses for high precision timers. For example, you can capture signals from IR and RF remotes via LineIn if you have a high resolution timer.

For Linux, see...

• http://elinux.org/High_Resolution_Timers

I don't know about OS-X.

EDIT: It appears there is a way to get 1 µS resolution under Linux, Unix & OS-X...

• http://www.songho.ca/misc/timer/timer.html