IMHO, the outcome of the current implementation is a bit unintuitive, but that could be fixed by documentation updates that explain the implementation a bit.
The only other issue I see with the current implementation is that it does not make it easy to accurately schedule an event for a specific time in the future, unless you remember to call tick() before calling schedule_*. This could be addressed by adding a schedule_at() method that takes the absolute time that the callback should be accurately called at (subject to tick() call frequency etc). Thanks again. On Nov 30, 6:08 pm, "Alex Holkner" <[EMAIL PROTECTED]> wrote: > > On 30/11/2007, sol <[EMAIL PROTECTED]> wrote: > > > > The thing that seems strange / inconsistent to me is that the dt > > > reported to the callback is close to the requested duration, but the > > > actual amount of elapsed time is not even close to the reported dt. > > > > Since, as you point out, the internal OS timer is not actually started > > > until the next call to .tick() after the call to schedule_once(), then > > > the OS timer duration should be corrected to a value that factors in > > > the fact that there may be a time delay between when the schedule_* is > > > called and when the next .tick() is called so that the reported dt is > > > always, within reason, accurate. > > > > Basically it seems that _schedule_item should record the time that the > > > schedule_* was called, so that the desired end time of the callback > > > can be accurately calculated, even if there is a delay between when > > > schedule_* call and the next .tick() call. This way dt passed to the > > > callback would always be accurate relative to the actual amount of > > > time that has passed. > > There seem to be two issues: > > 1. The first timestamp is recorded when the clock module is loaded, > which can be significantly earlier than when the application starts > ticking due to the delay in creating the first window. > 2. The schedule_* functions use the last known timestamp instead of > the current time when determining the next scheduled time. > > The first issue can only be worked around by calling 'tick()' just > before entering your main loop (or scheduling anything), or by > creating another clock, as Rod suggests. This should completely solve > your particular issue, I believe. > > The second issue is a design decision, to ensure the following > scenario: 5 functions are scheduled for 1 second in the future within > the same tick. Those 5 functions should reasonably be expected to be > called within the same future tick. This cannot be guaranteed if the > scheduling time is used instead of the last timestamp time. > > Usually the discrepancy is not noticeable as tick() is called several > times per second -- this is a requirement of pyglet applications due > to the nature of dispatch_events() anyway (you can't insert an > arbitrary sleep() into your run loop), so I believe the behaviour is > reasonable. > > Debate/objections welcome! > Alex. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~----------~----~----~----~------~----~------~--~---
