but the resolution is not a ms at all. every call to gettickcount is something like 10-15ms or so off. you'd be lucky to call it a ms after it was updated by the os. do we document that too?

--
Alexander Grotewohl
http://dcclost.com

On Sep 7, 2019 7:41 PM, Martin Frb <laza...@mfriebe.de> wrote:

On 07/09/2019 21:42, Zoe Peterson wrote:
> GetTickCount and GetTickCount64 are Windows API functions that are
> explicitly documented as returning milliseconds, and FPC on Unix up to
> now is has matched that. Why in the world would you think that
> changing that behavior would be a good idea, *especially* if you keep
> the function name the same?!?
>
> As an FPC user, this seems like an astoundingly bad decision to even
> be considering.
>

I do back that.

vague-ness or "the absence of documenting" is  not the same as (from the
beginning on) documenting that "the unit is not given, *because* it may
*vary*"

I would suggest to amend the documentation to the current state.
Something like:
----

The length of a tick depends on the platform/OS/...
Therefore a tick can be a different amount of time on different targets.

For the following targets, the ticks are specified as follows. For other
targets they may change, until documented.
Windows: tick = millisecond
Linux: tick = millisecond
OSx/Mac/Darwin: tick = ?

The minimum resolution may vary, and may be more than one tick.
The function itself may also take a varying amount of ticks, and the
returned result may on top of resolution issues be outdated by any
amount of ticks.
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


_______________________________________________
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Reply via email to