|
|
Le mardi 6 juillet 2021 à 16:04:32 UTC+2, Albrecht Schlosser a écrit :
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).
The macOS FLTK platform uses a system timer: the event loop
is made by calling a function that does "wait until an event
arrives",
and Fl::add_timeout creates a system object that makes the
waiting function run the timer cb when the delay has expired.
Is it correct that this is one distinct system timer per timer queue
entry?
Yes, one system timer per queue entry.
My idea was to also use a true system timer for the Wayland
platform (but that could be for all Linux). Posix timers do
that.
They trigger either a signal or a thread after a specified
delay. With the thread approach, having the child thread call
Fl::awake(cb, data)
allows the main thread to stop waiting and process the
timeout cb.
Hmm, is this a necessary change for the Wayland platform, or do you
want to do it because you find the current implementation "awkward"?
No. The X11 implementation works with Wayland just as well as with X11.
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)
function.
As written above, the X11 approach uses the fd through
which all X11 data arrives and the poll/select call on this fd
to simulate
timeout events: it reduces the max waiting time of the
poll/select call. Is your idea to change the organization of
the event loop
of other platforms (namely macOS) and have it wait for GUI
events for a time determined by the next scheduled timeout?
I can't answer this question with yes or no.
My basic idea is to unify (and therefore simplify) the timer event
handling on all platforms. I've seen IMHO too much platform specific
code to handle timer events. The more platforms we add, the more
platform specific code we need to maintain.
My goal is to do as much as possible in platform independent code.
This platform independent code would schedule timer events by adding
them to the timer event queue - in my model the Unix/Linux code
would be a valid implementation. This could be done on all current
and future platforms in a platform independent way. There would also
be only one platform independent timer event processing function.
This could be (like) the current Unix/Linux implementation which
decrements the timer delay of all timer events in the queue.
The only platform dependent code should be the scheduling of the
timer event. This could be as it is now on Unix/Linux to reduce the
select/poll timer to the next timer delay or to schedule exactly one
system timer on each platform which would be the delta time to the
next (first) timer event. The only requirement is that the resulting
timer event would call the platform independent
process_timer_event() function.
For further clarification: my model would allow to use the fd
approach we're using now as well as POSIX timers and Windows or
macOS timers as long as we're only scheduling one timer for all
systems and we're doing the timer event processing in only one
system independent function. This is basically what I want to
achieve.
This would allow us to get the same behavior on all current and
future platforms including the optimal "repeated timer delay
correction" with the minimum of platform specific code. A nice side
effect would be that porting to another platform would be
simplified.
Good. I think I begin to understand more clearly what is your proposal. It requires to distinguish between timer queue entries and system timers and to have only one system timer. I had not envisaged this before. That seems to allow to much reduce the platform-specific part of timer support. I look forward your proposal.
--
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/af4ac075-8bcc-4003-8822-a163bd025ae0n%40googlegroups.com.
[ Direct Link to Message ] | |
|
| |