Repository navigation
Timer + long-running callback expectations #29029
Description
Do we want to say anything about how we expect our event timers to behave with regard to when they fire? Should a timer be ticking continuously and firing when requested regardless of other tasks occurring (maybe in a separate thread), or should the timers fire at (time in callback + interval)?
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.
import time
import matplotlib.pyplot as plt
fig = plt.figure()
def on_timer():
print(time.ctime())
time.sleep(1)
timer = fig.canvas.new_timer(interval=1000)
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.
Originally posted by @greglucas in #29023 (comment)
Activity
jklymak commentedon Oct 28, 2024
You can imagine either behaviour is desired. Certainly it should be the same between backends!
anntzer commentedon Oct 29, 2024
Timers are internally mostly (only?) used for animations, and if I request a 1fps animation I don't care how much time matplotlib takes to render the canvas, so I would think that requesting a 1s interval should lead to a trigger every second (to the extent where this is possible), even if the callback takes 950ms to execute?
tacaswell commentedon Oct 30, 2024
I'm also in favor of doing our best to hit the requested trigger rate (independent if we spend that time doing stuff or letting the event loop twiddle its thumbs).
QuLogic commentedon Oct 31, 2024
What do you intend to happen when the callback takes longer than the timer duration?
anntzer commentedon Oct 31, 2024
Then we just run as fast as possible?
QuLogic commentedon Oct 31, 2024
But does the callback overlap or only run once after?
anntzer commentedon Oct 31, 2024
I think they all run in the same thread, so they can't overlap, can they?
QuLogic commentedon Oct 31, 2024
Sorry, not overlap, but bunch up. Say you have a 1-second timer, and your callback takes a fraction of second, except one time it's doing file I/O or something, and takes 5 seconds. Do you get one call at the sixth second after that one started, or 5? Your "as fast as possible" could be interpreted either way.
Now, I'm pretty sure all our toolkits say that you will get 1, but if we start fiddling with things, then we should codify that that's what we expect as well.
anntzer commentedon Oct 31, 2024
Good question. I would probably go for option 1, but it's not something I have properly thought about.
greglucas commentedon Oct 31, 2024
Currently all timers are added to the main thread of the respective toolkit, and all work is also scheduled on that thread (unless the callback spawns a separate thread itself). This means that the timer doesn't fire during the long callback, so there is not a buildup of events.
An example script to demonstrate all of this and the current inconsistencies between backends is here:
All backends skip forward without any events during the first interval (and without a large emittance of events after that period).
qt
tk
macosx
gtk4
wxagg
I have a few separate PRs up making these more consistent, but maybe I should merge them all into a single PR so it is easier to review since there are multiple overlapping issues that need to be fixed in the above examples.