On 05/21/2014 07:46 PM, Graeme Geldenhuys wrote:
...
(This was no FUD, as the _officially_released_ (ZIP) distribution really
suffers from the restriction I described. Don't be angry on me pointing
this out. No pun to the good work done.)
As I said, EpicTimer doesn't have a GUI dependency since 4 years ago
when I patched it. Please get an update from Lazarus-CCR's SubVersion
repo, or get even later code from my Github repo (details posted in
another message).
After Sven pointed me to the version of the code you talked about, I of
course immediately tested it and found that you are right: it does not
have such dependencies and I can easily _use_ "epictimer.pas" in the
interfaces.pas unit that I am doing for ActiveNoGUI.
Now I really would like to see the file epictimer.pas in the fpc rtl svn !
I will continue the work on ActiveNoGUI depending on epictimer.pas
instead of any internal implementation of access to a timebase.
Here I'd like to consider some suggestions (I of course can implement
this locally and we can later discuss a release for the fpc RTL or whatever.
- function GetHardwareTicks could be a class function so I wold not
need to create an instance to use it
- FHWTickSupportAvailable could be calculated in the initialization
section so that it is not necessary to re-do this for any instance.
- property HWTickSupportAvailable could be a class property, as a
consequence.
- I'd like to use a "GetTicks" class-function that provides raw ticks
and automatically uses GetHardwareTicks if FHWTickSupportAvailable and
software ticks if not.
This done we might consider using vDSO in Linux to provide straight arch
independent support for all Linux systems.
-Michael
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
