Great info. Thanks for sharing this Claudio. 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.
