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
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
My public PGP key: http://tinyurl.com/graeme-pgp
fpc-pascal maillist - firstname.lastname@example.org