Ah, the penny drops. I misunderstood your question. The first time I ran
your program I ended up with an error of more than 4 seconds. It did take
quite a while for my window to appear the first time, so I wonder if that
has something to do with it.
dt = 4.269 / elapsed = 0.020 / ERROR: -4.249
dt = 2.015 / elapsed = 1.995 / ERROR: -0.020
I think I know what's going on now. Here's the line in tick() that invokes
the callback.
item.func(ts - item.last_ts, *item.args, **item.kwargs)
When the callback is invoked, its 'dt' parameter is set to ts - item.last_ts,
where ts is the current time. I suspect that the problem is item.last_ts is
not being set correctly.
Looking at schedule_once(), it calls _schedule_item(). That sets last_ts as
follows...
def _schedule_item(self, func, interval, repeat, *args, **kwargs):
last_ts = self.last_ts or self.next_ts
self.next_ts is set in Clock()'s constructor, ie, self.next_ts = self.time
().
I suspect the problem would go away if you created your own clock rather
than using the default one, as that is created when the module loads. If it
takes a while to create the window after the clock is initialised, that
would account for the long elapsed time.
Here's a new version of the code that doesn't use the default clock.
from pyglet import clock
from pyglet import font
from pyglet import window
win = window.Window()
ft = font.load('Arial', 36)
text = font.Text(ft, 'Hello, World!')
klock = clock.Clock()
tstart=None
def callback(dt):
global tstart
print "dt = %.3f / elapsed = %.3f / ERROR: %.3f" % \
(dt,clock.time.time()-tstart,clock.time.time()-tstart-dt)
tstart=clock.time.time()
klock.schedule_once(callback,2.0)
tstart=clock.time.time()
klock.schedule_once(callback,2.0)
while not win.has_exit:
win.dispatch_events()
klock.tick()
win.clear()
text.draw()
win.flip()
win.close()
Here's the output...
dt = 2.013 / elapsed = 2.013 / ERROR: 0.000
dt = 2.002 / elapsed = 1.962 / ERROR: -0.040
dt = 2.013 / elapsed = 1.953 / ERROR: -0.060
dt = 2.002 / elapsed = 1.962 / ERROR: -0.040
QED
--- Rod
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.
>
> Maybe I'm thinking of this the wrong way though.
>
> Thanks.
>
> Sol
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
