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. On Sunday, April 9, 2023 at 6:26:19 AM UTC+3 s.ma...@gmail.com wrote: > 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>: > > > > 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. > > > > -- > > 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 > . > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/pyglet-users/4c8f023f-a793-417d-ae04-66bef22af76dn%40googlegroups.com.
