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.
