Is more consistent time intervals (dt) for Clock.schedule something you desire? I can understand why it is inconsistent, because it effectively causes pyglet to never sleep (in most circumstances). This condition probably makes the OS schedule pyglet worse. Have you tired the FPS limit in addition to Clock.schedule?
I imagine that my clock implementation would have the same results. The heap clock is gives better performance when scheduling items in the future, rather than each tick. However, there is a bit of code in the EventLoop that was made for windows XP, but because it was left a bit unfinished, it is applied to all systems. That may be in part why you are experiencing choppiness. The code is Eventloop._run_estimated. https://bitbucket.org/pyglet/pyglet/src/e659fae045543ff6c09f4f0258b501015ec6e873/pyglet/app/base.py?at=default&fileviewer=file-view-default#base.py-159 By adding a runtime check for Windows XP, I expect that it could be more consistent. Using the high performance timer in python 3.4 should also help mitigate those problems. As for wall time comparisons, that is something that I've never tested. On my personal fork of pyglet, I began to move all time related functions out of pyglet.app.base.EventLoop. If I were to do this to pyglet here, then I think that it will restore pyglet 1.1.4 clock behavior. Any other comments about the clock/scheduler/event loop? Thanks for all the detailed info...it will help improve pyglet, and cocos :D On Thursday, October 29, 2015 at 5:19:45 PM UTC-5, claudio canepa wrote: > > > On Thu, Oct 29, 2015 at 3:54 PM, Rob van der Most <[email protected] > <javascript:>> wrote: > >> Indeed. Although I would focus on the built-in event loop, as the other >> way is already slightly broken. Also the documentation of using your own >> event loop is already incomplete. >> >> @Claudio, what do you use for Cocos? >> >> >> > cocos uses pyglet event handling, with the stock pyglet event loop. > > For some applications and debugging I used in parallel the pub-sub library > blinker [0] . The advantage is that you can subscribe without a reference > to a publisher. > > Two things about clock-events-mainloop > > - For testing it is important that code using pyglet can control the clock > dt > Actual use case in cocos: > 1. setup a dynamic scene > 2. for dt in [d1, d2, ...]: > tick pyglet clock by dt > take snapshot and save > 3. compare snapshot with reference snapshots > Notice we need not wait or produce unneeded ticks, and the time in the > snapshoots will perfectly match the reference. > > - A use case for controlling the clock from user code is to render a > complex scripted scene with a perfectly smooth framerate [ we have api to > do this in cocos ] > > cocos uses custom clocks to do this: > - the pyglet 1.1.4 is the simpler, and easiest to inject: simply > replace pyglet.clock._default with the custom one > > - pyglet 1.2+ clock was more tangled with the event loop, besides > replacing the pyglet.clock._default we needed to set > pyglet.app.event_loop.clock and monkey patch > pyglet.app.event_loop._run_estimated > > ** So, if refactoring pyglet clock - eventloop, please try to keep simple > the clock substitution ** > > - Another thing: actions (changes along the time) in cocos are updated by > subscribing with clock.schedule , and I see choppiness. > Testing the pyglet example noisy.py in same machines, it run smooth > It uses clock.schedule_interval, and the cpu load on a dual core is 0.02% > Replacing with clock.schedule, I see the choppiness, and cpu load 50% > > Scheduling a function that stats the dt's shows deviations from the > expected value beyond 240% > > I had not tested, but would be interesting, how pyglet dt's compares with > HighPerformanceCounter based dt, nor how the sum(dt) compares with wall > time. > > An old machine with win XP and intel graphics don't shows the defect, a > win7-32 bit + ati gpu shows the defect, and I have seen that in other > machines. I think vsync=True is involved. > > I have not tested with the Leif clock variant to see if it makes any > difference, will do but can't promise a timeline. > > So, if refactoring clock-events-mainloop, keep an eye on the event > dispatch + vsync case > > Just for reference, the script to stat noisy.py [1] , with the stats > captured in the win7-32 bits + ati gpu as comments > > [0] https://pythonhosted.org/blinker/ > [1] http://pastebin.com/vr2qnszi > > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
