I'm writing this because ... |
On 7/5/21 3:09 PM Manolo wrote in
thread "About mixing Fl::awake(Fl_Awake_Handler, void*) and
I'm asking because I'm exploring the use of Posix timers to
for the Wayland platform (see the timer_create() and
These functions allow to trigger the timer either as a signal
or starting a thread.
I've chosen the thread option, and have the thread call
so that the timer's callback gets then called by the main
thread in its event loop.
@Manolo: Before you dive too deep into a specific implementation for
Wayland I'd like to share some thoughts I'm having since some time
now to unify the timer handling on all platforms. I believe that the
Linux timer implementation is superior to the Windows and maybe also
the macOS implementation. The Linux timer implementation works like
this (maybe over-simplified):
(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.
The benefit of this approach is as described in Fl::repeat_timer()
docs: if the call to Fl::repeat_timer() is done "late" it can be
corrected by the delay and the overall timer sequence of repeated
timers is more accurate than on other platforms.
On the Windows platform we're (AFAICT) using one system timer per
Fl::add/repeat_timer() call. The Windows timer events are less
accurate anyway, but a change as designed for Unix/Linux could
probably contribute to more accuracy of repeated timer events
because the correction of timer delay as on Unix/Linux could work
better (it does not currently on Windows).
I know less about the macOS platform, but I know for sure that the
timer handling is different. There are inconsistencies WRT
Unix/Linux/Windows on the user visible level (which I intend to
demonstrate with a test program anyway) but which are too difficult
(and OT now).
That all said: I hope that the Wayland implementation would be
basically like the Unix/Linux timer queue handling so we can easily
unify all platforms.
More about the unification: I'm thinking of a platform independent
timer queue where Fl::add_timeout() and friends would be platform
independent. They would add an Fl_Timeout_XX object to the timer
queue which may contain platform specific timer data (or
not?). Triggering the timeout would then, as always, be done by the
system, the timer queue handling would still be platform
independent, as well as calling the callbacks etc.. The more I think
about it, the more I believe that only the scheduling of this single
timer event would be a platform dependent (i.e. system driver)
Comments welcome, particularly from Manolo but also from other devs.
If I'm not missing anything (are there any drawbacks?) I could start
soon to develop a new timeout handling model which does all of this
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 email@example.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/7bf6c876-8c0e-6ad7-a31f-834276e3ee50%40online.de.
[ Direct Link to Message ]