Timer events do not expose a 'time_since_last_frame' attribute about vispy HOT 10 CLOSED

I do not think this is in the scope of the Timer object, but it could certainly be added to Canvas.

from vispy.

We could provide at least the dt since last tick (it is quite useful and it saves the user the manipulation of time).

Nicolas

On Aug 25, 2013, at 2:45 PM, Luke Campagnola [email protected] wrote:

I do not think this is in the scope of the Timer object, but it could certainly be added to Canvas.

---

Reply to this email directly or view it on GitHub:
#28 (comment)

from vispy.

That's true.. there's a complication in that the timer can have multiple callbacks. Generally, each callback will want to know the time elapsed since that callback was last invoked (if one callback takes a variable amount of time, then subsequent callbacks would have an inaccurate measure of timestep). This would not be too difficult to implement, but the timer would need to keep track of the timing for each callback, probably with a subclass of EventEmitter.

from vispy.

Can we not assume (and document) that in a situation where timing is crucial, a custom timer will be used with just one callback?

From a look on the code, it seems that keeping track of time per callback is quite complicated (and hackish), while keeping track of the last tick is trivial.

from vispy.

That's not good. Getting elapsed time since last call is a very basic feature and if the current app architecture doesn't allow to implement this, we may want to reconsider the whole thing.

Again, pyglet is doing just that and quite precisely (even taking account clock over/under shoot) and thus, we might just to exract the clock.py object from pyglet.

from vispy.

I don't think this is due to the design of our event system. It is inherit to each design that supports multiple event handlers on a timer. So as long as a user in need of precise timings just adds a single handlers, all should be well.

Perhaps we should add some sort feature that can ensure that there is a single handler? For instance via an argument to the Timer class?

from vispy.

Not sure I understand.

Let's say I want a timer with 1/50 frequency and a second one with 1/20 frequency, how would I write that ? Maybe an example in app would be good. And of course, I would like to get dt in args/event since last tick in each timer, ~1/50 in first one, ~1/20 in second.

On Sep 1, 2013, at 8:12 PM, Almar Klein [email protected] wrote:

I don't think this is due to the design of our event system. It is inherit to each design that supports multiple event handlers on a timer. So as long as a user in need of precise timings just adds a single handlers, all should be well.

Perhaps we should add some sort feature that can ensure that there is a single handler? For instance via an argument to the Timer class?

---

Reply to this email directly or view it on GitHub:
#28 (comment)

from vispy.

Like this?

def callback1(event):
    timesincelastcall = event.dt  # This does not yet work, but we might do it like this
timer1 = app.Timer(1.0/50)
timer2 - app.Timer(1.0/20)
timer1.connect(callback1)
timer2.connect(callback2)

from vispy.

Yep exactly. Also dt should be time since last calling each callback (around 1/50 for callback1 and 1/20 for callback2)

On Sep 1, 2013, at 8:36 PM, Almar Klein [email protected] wrote:

Like this?

def callback1(event):
timesincelastcall = event.dt # This does not yet work, but we might do it like this
timer1 = app.Timer(1.0/50)
timer2 - app.Timer(1.0/20)
timer1.connect(callback1)
timer2.connect(callback2)

---

Reply to this email directly or view it on GitHub:
#28 (comment)

from vispy.

Timer events now have .dt attribute.

from vispy.