[fpc-pascal] The unfortunate deprecation of GetTickCount

Graeme Geldenhuys mailinglists at geldenhuys.co.uk
Thu Apr 12 20:50:18 CEST 2018


On 2018-04-12 07:39, Michael Van Canneyt wrote:
> Ah, finally !
> I was waiting for epiktimer to pop up in the discussion...
>
> Thank you, Graeme :-)

Not sure if that was meant as sarcastic or not. I mentioned EpikTimer,
because it rolls most use cases into one easy to use class. Plus
EpikTimer allows many other functionality too - like tracking multiple
independent timers etc.


>> It uses the highest resolution timer it can find on each platform, and
>> GetTickCount/GetTickCount64 as a fall-back
> 
> No, it doesn't. I just checked.

Ah, I see now it has its own newGetTickCount() implementation - I guess
the similar name threw me off.


> Maybe it used it at one point, but changed to a custom implementation to be
> able to switch to clock_time ahead of FPC.

That sounds vaguely familiar, so you might be right.

I had a quick look in FPC 3.0.4 and I see FPC also uses
clock_getTime(CLOCK_MONOTONIC). As you said, I guess the EpikTimer
implementation predates FPC's GetTickCount64. But now that FPC has that,
EpikTimer could most likely switch to using it, instead of its own
implementation - at least for the relevant parts of EpikTimer.


> I suggest fixing at least the bug.

I'll do that, thanks. I just noticed I have some local mods/improvements
(done 1-2 years ago) and still haven't updated the Git repository
either. I'll get those in promptly.

I think it would be good to delve into Java's System.nanoTime()
implementation too, and see how that translates to various platforms.
The nanoTime() frequency is really small - not 1 nanosecond, but still
very small.


Regards,
  Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp



More information about the fpc-pascal mailing list