Just wanted to say thanks for the info on the new Python 3.4+ time.perf_counter(). That news completely passed me by.
I don't have enough experience with pyglet yet to comment on this, but I've struggled with timing issues with other libraries in the past and am glad that this is being worked on. On Saturday, October 31, 2015 at 2:30:40 AM UTC+9, Leif Theden wrote: > > 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]> >> 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.
