[Customdrawn] LazClock exercise

[Giuliano Colla]

Il 02/04/2012 09:32, Michael Schnell ha scritto:
> On 04/01/2012 01:47 PM, Giuliano Colla wrote:
>> With Customdrawn and original timer sometimes you see the seconds 
>> hand jump two seconds (meaning that it missed a tick), with new timer 
>> you see it a little less, but that's all.
>>
> IMHO: TTimer is specified not to miss an event, unless the main thread 
> is busy for at least a complete period.
>
> So missing a tick with a not very busy Project should be considered a 
> bug, while delaying the event start for any amount of time less than a 
> complete period for an arbitrary reason is allowed.
>
> If the main thread is busy for more than a complete clock period, it 
> is debatable what should happen, what should be allowed and what 
> should be considered a bug:
>  - forcibly miss all but one tick (delete all registered timer events 
> when one is handled)
>  - forcibly do all delayed ticks that occurred in the past in a row 
> (count the ticks and schedule them all ASAP, stalling other (GUI and 
> thread) events at that point in time)
>  - forcibly do all delayed ticks that occurred in the past merged with 
> other Events (blur the Event queue by scheduling each timer event at 
> it's own.
>  - do _some_ events and miss _some_ ticks
>
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.
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.
In many other cases the opposite is true.
I think that
1) Everything should be fast and efficient enough to make such a case 
extremely rare.
2) The option of what to do should be left to the application, with an 
extra option in TTimer.