| |
| |
I absolutely agree that the simpler approach where code is shared is right. Most of the fltk timer code is just to provide a convenient api. Internally the moment Fl::wait() is called it know exactly how long it is until the next time. All it needs to do in system-specific code is wait at most that amount of time for an event to come from the user interface. I think most systems have a timeout on the "wait for an event" function, it would be implemented using that. It would not use any "timer events" provided by the system. There is some more difficulty with also waiting for feedback from other fd's, that I think does require some variation between platforms. The last I remember it was just punted on Windows, adding an fd to listen to in fltk did not work, or at least delayed the response until a UI event came in. This may not be as big of a problem as it sounds, as the only reason the fd monitoring is in fltk at all was because it was a trivial addition to the X11 version.
On 5 Jul 2021, at 21:02, Albrecht Schlosser wrote:
>
> (1) Every call to Fl::add_timeout() or Fl::repeat_timeout() adds a timer entry to the internal timer queue. This queue is sorted by the timer's due time.
>
> (2) There's only one system timer, using the smallest delta value, i.e. the time of the first timer in the queue.
>
> (3) Whenever the timer triggers (or maybe more often) the event handling decrements the delta time of all timers.
>
> (4) All timers callbacks of expired timers are called.
>
> (5) A new timer with the shortest delay (which is always the first timer in the queue) is scheduled.
>
> (6) Wait for timer events...
>
> This is AFAICT done because the standard Unix timers can be interrupted and need to re-scheduled whenever such interrupts occur.
Also, since that design was created, it is possibly worth considering that the major desktop OS now tend to apply timer coalescing, at least to some extent, which would not have been the case in times past...
What this means is that the OS tries to shuffle as many timer-related events as possible into a smaller set of time slots, so that at each time slot it can execute “all” the pending events then sleep the CPU (or at least drop the CPU into a lower power state) and thus minimise power/heat and maximise battery life etc.
I don't know if that would affect how we think about this issue or not, though.
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/42064247-9E8D-48B7-846F-E9BEDD261F81%40gmail.com.
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/CAL-8oAhHaFwKZTAqXptK3dMPGXRrn_tvCGaMY3%3DsBRxOcVngAw%40mail.gmail.com.
[ Direct Link to Message ] | |
|
| |
