[Customdrawn] LazClock exercise

[Felipe Monteiro de Carvalho]

On Mon, Apr 2, 2012 at 10:08 AM, Giuliano Colla
<giuliano.colla at fastwebnet.it> wrote:
> I'm convinced that there's no solution good for all cases. Depending on the
> usage of a timer, you may either want that it keeps a perfectly constant
> rate, or that it provides you the best it can.

I think that TTimer is by definition a timer with a good hability to
mix events into the main loop but whose precision is low and will vary
across widgetset. So we should focus in optimizing for a good mix of
events in the main loop and for avoiding delaying timer messages for
more then 100ms if possible. That should improve things for LazClock
for example.

About your previous idea of threads: I think that threads cannot be
utilized unless as a non-activated by default define because by
definition LCL apps do not need threading support by default.

> If you're sampling data from a measuring instrument, and need data 1ms
> apart, it is preferable to have data at time 1 - 2 - 4 - 5 - 6, than data at
> time 1 - 2 - 3.9 - 4.9 - 5.9.

Then they are using the wrong component for the task. TTimer is not
suitable for talking to hardware, unless your precision is very low
(like 100ms). That the minimal resolution of TTimer is theorically 1ms
is just a theory, I doubt it really is close to that in LCL-Win32,
LCL-Gtk, LCL-Cocoa, etc. Even in LCL-CustomDrawn I have no idea how is
the precision of the Android timer for example, since the API in
question does not guarantee any precision at all...

People that need such special timer precision really need to use a
dedicated thread for talking to the hardware, make a loop in that
thread and use a precision timer counting component (like EpikTimer)
in a loop. TTimer is a native timer (where available) so it cannot be
relied upon for high precision. Another idea would be expanding
EpikTimer to support a higher level interface which builds a loop and
adds event-driver programming, but all of this is unrelated to
implementing TTimer.

> 2) The option of what to do should be left to the application, with an extra
> option in TTimer.

Unlikely to be useful if CustomDrawn-X11 would be the only one to
support the high precision variant.

In Android at least implementing the high-precision variant of TTimer
is impossible. The main thread cannot be controlled in Android, and
the only way to get a good result would be the solution which I
presented before: spawn a new thread and make a loop in it. But this
offers no mixing of events into the main thread at all and the code is
not running in the main thread. If you want to run the code  in the
main thread you could theorically send messages to it and synchronize,
but then you loose the precision because you don't know how long the
main thread will take to answer.

So summing up, I think that TTimer is unsuitable for high-precision
applications by design.

-- 
Felipe Monteiro de Carvalho