Animating shapes with event handlers

[Matan]

Hi and thank you for pyglet.

Let's say I have some pyglet shapes I wish to animate ― move them around or make them grow or shrink gradually (tweening). If I handle this by stacking and `update` and `draw` events, then it seems that the event stacking architecture implies that I cannot stop an animation A which started at some point in time before some other animation B  which started after A will have finished, because the event handlers can only be popped in the order by which they were pushed ― if animation B started before animation A has finished, the event handlers I pushed for event A cannot be popped without popping B first. 

Is that so?

Of course I could keep all animations pushed as `update` and ` draw` event handlers go idle by conditional logic, but this will leave zombie event handlers lying around, making it inappropriate to design each animation as a unit of execution on loop events. 

How would you design for making shape animations which have arbitrary start and end times relative to each other, meaning that their start and end times are not serial to the start and end time of other animations?

To reiterate, when speaking here of 'animations', I am referring to animating pyglet shapes (or even making other types of tweens such as fade ins/outs) by changing their attributes on `update` ticks. 

As much as it matters my application is highly event driven, events can be keyboard input but also many other things which arise from camera input real-time analysis. 

Thanks for your suggestions or comments if you have a suited and robust design  pattern suggestion using pyglet.

Matan

[Greg Ewing]

On 8/04/23 12:26 am, Matan wrote:
> Of course I could keep all animations pushed as `update` and ` draw`
> event handlers go idle by conditional logic, but this will leave zombie
> event handlers lying around, making it inappropriate to design each
> animation as a unit of execution on loop events.
>
> How would you design for making shape animations which have arbitrary
> start and end times relative to each other, meaning that their start and
> end times are not serial to the start and end time of other animations?

Create an object with an uopdate() method to manage each animation
and keep a list or other collection of active animation objects.
Then you can have just one event handler permanently installed that
calls the update() method of all active animations. That way you
can stop an animation at any time just by removing its object
from the active list.

--
Greg
This email may be confidential and subject to legal privilege, it may not reflect the views of the University of Canterbury, and it is not guaranteed to be virus free. If you are not an intended recipient, please notify the sender immediately and erase all copies of the message and any attachments.

[Сергей Матвиив]

Thanks for the advice.
Do you have a code example of how to implement this?

вс, 9 апр. 2023 г. в 02:11, 'Greg Ewing' via pyglet-users
<pyglet...@googlegroups.com>:

> --
> You received this message because you are subscribed to the Google Groups "pyglet-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pyglet-users...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/pyglet-users/80cfcab9-c2ce-7198-2ac9-d2aa0e91f6e1%40canterbury.ac.nz.

[Matan]

I implemented this right after posting here, which coincides with the suggestion from Greg: https://github.com/pyglet/pyglet/issues/772#issuecomment-1503807067

It is however not entirely trivial, since there are some concurrency-like considerations when working outside the core eventing implementation which pyglet implements. E.g. notice there the handling for only allowing callbacks to execute after any update of the callbacks registry is atomically complete. Maybe the same considerations also apply even when using the regular pyglet api, in which case I wonder if you are using a different recipe for that kind of integrity. 

Being safe in the face of asynchronous invocations is always tricky. AFAIK from once reading its source pyglet uses just one thread for the event loop. If you have a more solid recipe for general thread safety in your pyglet based application please do chime in.