I added a "replay" mode to Enjuewemela [0], for debugging purposes.
This means that after you played some game, you can do...
cp ~/.cache/enjuewemela/enjuewemela.log /tmp/
bin/enjuewemela replay /tmp/enjuewemela.log
...and then it will show you the initial board in your game, and you
can navigate all that you played using the arrow keys.
This is a very "static" simulation of the game. IOW, unless you press
a key, nothing happens [1]. Initially you have the board, 64 gems, and
nothing more.
However, it uses a lot of CPU. Why? Here goes my analysis.
At first I found it's throwing too many FPSs. Normally 28 and 35,
without doing anything, which is very strange. Why? The cocos2d
director.on_draw() method was being called each ~30ms.
Why? pyglet's BaseEventLoop.idle() (in app.py) was being called a lot
too (it redraws all windows).
Why? in pyglet's app/xlib.py there's XlibEventLoop with the run()
method that handles the control loop. It basically do:
1. check if there're pending events for any display
2. if not, does a select.select() with a 'sleep_time' timeout, waiting
for something to happen.
3. dispatch any pending event (found in 1 or 2)
4. dispatch resize events, if any window needs resizing
5. call self.idle() (the BaseEventLoop one I commented before), which
returns the 'sleep_time' for the select.select() of step 2 above.
What is very weird is that the select ends fast with nothing to do.
I'll explain that a little more. The loop starts with a sleep time of
0.7 seconds, for example, and in step 1 it doesn't find any pending
events. It does the select.select() in step 2, and it passes right
away (it doesn't waits 'sleep_time'), returning some pending_displays.
However, in step 3, those pending displays has no pending events
(!!!). In step 4 nothing is sent either. Step 5 redraws everything,
getting another big 'sleep_time' that will ignored later, and so on.
Specifically, in step 3, the sequence is:
for display in pending_displays:
while xlib.XPending(display._display):
...
Of course it executes the 'for' ok ('pending_displays' has a valid
value, returned from the select()), but it then never gets into the
'while'.
So, that would be the weirdness: somebody is writing into the display,
making the select() exit fast, but with no real pending events to
dispatch.
Does anybody have a clue about why this is happening? I'm setting
stuff somehow incorrectly from the game producing this nasty side
effect? Is a behaviour change in xlib that pyglet should handle
better? Should I send a similar mail to pyglet mailing list?
Thank you very much!!
[0] Need trunk to see it, do "bzr branch lp:enjuewemela", and then
"bin/enjuewemela" inside it
[1] For this 'replayer' I don't care about the mouse, but to test all
described here assure yourself that you're not moving the mouse over
the game window, which *will* produce events to dispatch.
--
. Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
Twitter: @facundobatista
--
You received this message because you are subscribed to the Google Groups
"cocos2d discuss" 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/cocos-discuss?hl=en.
