> 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 -~----------~----~----~----~------~----~------~--~---
