I should have also mentioned that we are overriding the time_function in Clock to use our high resolution timer.
On Dec 4, 7:23 am, sol <[EMAIL PROTECTED]> wrote: > I think a little background would be good. > > We write software for vision scientists where accurate reporting of > stimulus changes (visual, auditory, or otherwise) is critical. Very > often the programs will make changes to the display and then wait for > an event to happen before doing something else, like changing the > display again or play a sound or send a TTL signal to another device > etc. This means that there are periods where the refresh rate of the > display can gate the frequency of polling (like calling tick() or > calling dispatch_events), but much of the time polling can be done > many times a millisecond. > > This is the type of situation where having a mechanism for accurately > scheduling a callback for a future time is very useful. > > I believe the issue with the current implementation of schedule is > that if you call schedule_* during a period of low tick() call > frequency then this effects the ability of the scheduler to accurately > schedule the callback for a specific time even when the time in the > future has a very high tick() call frequency. Again, this is all fixed > in the current implementation if I call tick() right before calling > schedule, so no biggy here. > > Thanks. > > On Dec 3, 8:30 am, "Alex Holkner" <[EMAIL PROTECTED]> wrote: > > > On Dec 4, 2007 12:14 AM, sol <[EMAIL PROTECTED]> wrote: > > > > 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. > > > I'll revisit the documentation and try to clear it up a little. > > > > 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_*. > > > I disagree that this is actually an issue. The current behaviour > > means that the error in calling a scheduled function is within one > > period of the tick() rate. Assuming you're calling tick() as often as > > you're calling flip() and dispatch_events(), this is the actual limit > > in responsiveness of the application anyway. The only reason it could > > noticeable to the user is if the tick() rate very low, say, below > > 10fps -- in this case the application is likely to respond poorly in > > any case, and would probably be better implemented using separate > > threads or processes. > > > I get the feeling that you're actually after some very accurate timing > > data, beyond merely scheduling functions for animation and similar > > purposes. If this is the case then pyglet.clock is probably > > unsuitable -- high resolution timers that exceed the 10ms resolution > > of the system clock are available on Linux and Mac (and, with some > > care, on Windows). > > > > 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). > > > The current clock class does not expose an absolute time property, so > > that would also need to be added if schedule_at() were considered. > > > 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 -~----------~----~----~----~------~----~------~--~---
