[fpc-pascal] The unfortunate deprecation of GetTickCount
R0b0t1
r030t1 at gmail.com
Wed Apr 11 18:44:11 CEST 2018
On Wed, Apr 11, 2018 at 11:26 AM, Alexander Grotewohl <alex at dcclost.com> wrote:
> The documentation seems fine. I can use it to approximate that a minute has
> elapsed, or to keep track of frames per second for a game, but I'm not going
> to use it to control complex machinery.
>
> The GetTickCount documentation offers that most system timers are within the
> 10 to 16 millisecond range. So if windows (internally) updates GetTickCount
> every millisecond, it's count might look like this from boot:
>
This is related to something I meant to propose a while ago related to
a cross platform timing and alarm API. I do not think GetTickCount
should ever be used; instead, QueryPerformanceCounter makes more
sense. It is higher resolution and still portable. The Linux function
`clock_gettime` called with `CLOCK_REALTIME_HR` is more or less a
direct equivalent.
Cheers,
R0b0t1
> 0000
> 0000
> 0000
> 0000
> - 10 more times
> 0014
> 0014
> 0014
> 0014
> 0014
> - maybe 9 more times
> 0027
> 0027
> 0027
> 0027
> 0027
> - maybe 8 or 9 more times
> 0042
>
> So in this example, if you want to time something to happen EXACTLY every 10
> milliseconds, you'd miss 10ms by 4, 20ms by 7, and you'd skip 30ms.
>
> This is why you do stuff like:
>
> if (gettickcount - previous) > 10 then /* do something here */
>
>
> A solution for the gettickcount overflow I liked was something like:
>
> current:=gettickcount;
> if (current >= previous) then
> elapsed:=current - previous
> else
> elapsed:=(high(dword) - previous) + current;
> previous:=current;
> if (elapsed > ...)
>
>
> Alex
>
>
>
> On 04/11/2018 09:40 AM, Paulo Costa wrote:
>>
>> Unfortunate is the obscure wording you find on the documentation:
>>
>> https://www.freepascal.org/docs-html/rtl/sysutils/gettickcount.html
>>
>> "Description
>> GetTickCount returns an increasing clock tick count. It is useful for time
>> measurements, but no assumtions should be made as to the interval between
>> the ticks. This function is provided for Delphi compatibility, use
>> GetTickCount64 instead."
>>
>> One would think that GetTickCount64 would clarify things about the
>> interval between the ticks (just to be useful for time measurements) but:
>> https://www.freepascal.org/docs-html/rtl/sysutils/gettickcount64.html
>>
>> "Description
>> GetTickCount64 returns an increasing clock tick count. It is useful for
>> time measurements, but no assumtions should be made as to the interval
>> between the ticks."
>>
>> How can it be useful for time measurements if we don't know the units?
>>
>> Contrast to the Microsoft Documentation:
>>
>> https://msdn.microsoft.com/en-us/library/windows/desktop/ms724408(v=vs.85).aspx
>>
>> "Return value
>> The return value is the number of milliseconds that have elapsed since the
>> system was started."
>>
>> Of course, it is followed by some remarks about the real limitations but
>> at least we have some idea on what to expect.
>>
>> I know that, by being cross platform, GetTickCount64 can behave in
>> different ways on other environments but, just because of that, the user
>> should not be kept in the dark when using it.
>>
>> I know that the documentation effort is hard and many times we don't
>> appreciate the effort as we should, but please don't be so vague on this
>> entry.
>>
>> Paulo Costa
>> _______________________________________________
>> fpc-pascal maillist - fpc-pascal at lists.freepascal.org
>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
>
> _______________________________________________
> fpc-pascal maillist - fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
More information about the fpc-pascal
mailing list