Under almost all circumstances you want to useperf_counter orperf_counter_ns to track time intervals. I don't know how many years it would take to lose precision inelapsed_ms due to floating point error but you might as well head it off withperf_counter_ns.

Also, sometimes it may be appropriate to wait less than 1 ms to catch up to the desired time, which this branch can't handle. One could fix this by moving the math up above and branching onnext_interval > 0, but then the code would be doing a lot of useless math for theself._interval==0 case.

Good call on theperf_counter_ns(), just pushed that change.

Our timers shouldn't be relied upon for anything less than 1ms as we get our intervals in integer milliseconds. So I think if we want to sync to something faster than that we should punt to users and tell them to bring their own timers.

This did get me thinking though. I think (I should verify this and test it...) the other backends have a timer that will emit the callbacks and reschedule the timer right away, regardless of when the last callback finished. So I think you'd potentially have multiple callbacks running at the same time if the callback tooklonger than the timer.

i.e. in Tk here if I have a callback that takes 2.5 seconds, but my timer is 1s. I'd get function calls at (1, 4, 7, ...) But I think on the other backends I'd get (1, 2, 3, 4, ...) with a piling up of events that are all running depending on what thread they were dispatched to and whether they could be started then or not. I think that can be left for a follow-up though and the first step here is just syncing on the original requested time.

Following up with some results about what the various backends currently do for callbacks that last longer than the timers with the following test script that will either print ~1/second or every 2-seconds.

importtimeimportmatplotlib.pyplotaspltfig=plt.figure()defon_timer():print(time.ctime())time.sleep(1)timer=fig.canvas.new_timer(interval=950)timer.add_callback(on_timer)timer.start()fig.canvas.start_event_loop(10)

macos: 2-seconds
tkagg: 2-seconds
qtagg: 1-second
gtk4agg: 1-second
wxagg: 2-seconds

So I can't say we have a standard right now, or if we should even try to set an expectation of one or the other cases to make things consistent.