Hi,
Maarten recently mapped winmm:timeGetTime to kernel32.GetTickCount This rang a bell and now I found again the article where I read about it:
http://blogs.msdn.com/larryosterman/archive/2009/09/02/what-s-the-difference...
"So why are all these multimedia APIs using timeGetTime and not GetTickCount since the two APIs apparently return the same value? ... The answer is that they dont."
I cannot judge whether what's described there applies to Wine's timing. However the listed timings prove both values are different.
FWIW, I've determined long ago that timer increments in MS suffer from a 15.625ms granularity. This affects almost all applications in MS-Windows. For instance, JMeter(Java) always returns times that are multiple of this value, plus/minus rounding. It will tell you jobs took 15, 16, 31, 32, 46 or 47ms etc. Never 5, 12, 26 or 30ms! You can't use it to time short jobs. I've seen the same values in many other apps (not just Java) and several versions of MS-Windows. Heck, 46 and 47ms are even shown in the above URL in the dTicks column (as well as the next pair: 62 and 63ms).
Whatever you measure, you'll encounter this 15.625ms increment. Presumably, the high performance counters are not affected. But few apps seem to use these.
What's 15.625ms? Exactly 64 ticks per second ... and the linearisation of all returned values.
If you GetTickCount something that truly takes 29ms multiple times, you'll observe 31/32 deltas much more often than 15/16. (As the article says: "note that the deltas average to 55ms").
Regards, Jörg Höhle