100% cpu load with scheduled events

[Rob McMullen]

Using linux and the xlib event loop, I'm seeing 100% cpu load when I
have any events scheduled. Once there are no more events scheduled,
the load drops down to zero. Sample program attached.

I can't get pyglet to work in VirtualBox on WinXP so I'm not sure if
this is a platform-specific issue or not. Any ideas?

Thanks,

Rob

[Nathan]

With your timing it's a bit hard for me to tell, but if I bump
"interval" up to 3.0, then I see negligible CPU usage after
initialization the entire time, whether something is scheduled or not.
I'm on OS X 10.7.3 with pyglet from the repository about two months
ago.

~ Nathan

> --
> You received this message because you are subscribed to the Google Groups "pyglet-users" group.
> To post to this group, send email to pyglet...@googlegroups.com.
> To unsubscribe from this group, send email to pyglet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
>

[claudio canepa]

No problem in winXP

 

[Rob McMullen]

Thanks for checking on the other platforms -- looks like it must be a
xlib problem. I was able to fix it for me with a small change in
pyglet/app/xlib.py:

--- a/pyglet/app/xlib.py Wed Mar 21 12:59:32 2012 +0000
+++ b/pyglet/app/xlib.py Wed Apr 11 07:44:29 2012 -0700
@@ -110,7 +111,7 @@

# If nothing was immediately pending, block until there's activity
# on a device.
- if not pending_devices and (timeout is None or not timeout):
+ if not pending_devices and (timeout is None or timeout > 0.0):
iwtd = self._select_devices
pending_devices, _, _ = select.select(iwtd, (), (), timeout)

I think the second timeout condition is reversed, because the select
should be called when there is a timeout, but NOT called if the
timeout is explicitly zero. In the original coding, bool(timeout)
returns True when timeout is not zero, so "not timeout" returns True
(and therefore the select clause is executed) iff timeout is zero. So
the only way the select was called is when timeout == 0, but select
called with a timeout of zero just returns immediately.

Rob

[Andreas Schiefer]

On Wed, Apr 11, 2012 at 4:57 PM, Rob McMullen
<ro...@users.sourceforge.net> wrote:
> Thanks for checking on the other platforms -- looks like it must be a
> xlib problem.  I was able to fix it for me with a small change in
> pyglet/app/xlib.py:

I was able to reproduce it under linux and also verified that your patch works.
The patch is now applied as of rev. 78160086c391.

Andy

[Nathan]

Yay!

Open source += 1

~ Nathan

[claudio canepa]

Maybe you can close / follow up issue 570 ? Was started by the OP in parallel with this thread. 

[Rob McMullen]

On Fri, Apr 13, 2012 at 5:33 AM, claudio canepa <ccan...@gmail.com> wrote:
> Maybe you can close / follow up issue 570 ? Was started by the OP in
> parallel with this thread.

I'm not sure if I created confusion with issue 570 and this mailing
list email thread -- issue 570 is actually a different fix for a
different case of 100% cpu usage in xlib.py. Issue 570 is related to
a call to post_event and the patch included in that issue I think
fixes the intent of the select call.

I'm new to both pyglet and the mailing list and wasn't sure of the
best way to report issues -- bug tracker or mailing list. I opened a
few issues recently in the bug tracker but didn't see any feedback so
I thought I'd try the mailing list for the scheduled events issue.

Rob

[claudio canepa]

On Fri, Apr 13, 2012 at 1:14 PM, Rob McMullen <ro...@users.sourceforge.net> wrote:

On Fri, Apr 13, 2012 at 5:33 AM, claudio canepa <ccan...@gmail.com> wrote:
> Maybe you can close / follow up issue 570 ? Was started by the OP in
> parallel with this thread.

I'm not sure if I created confusion with issue 570 and this mailing
list email thread -- issue 570 is actually a different fix for a
different case of 100% cpu usage in xlib.py.  Issue 570 is related to
a call to post_event and the patch included in that issue I think
 fixes the intent of the select call.

My bad, I spotted similarities and pass over the differences. Sorry for the noise.

--

claudio 

[AdamGriffiths]

Don't forget that Pyglet creates an 'on_draw' event every time the event queue is emptied.

http://pyglet.org/doc/api/pyglet.window.Window-class.html#on_draw

I monkey patch the idle loop in my framework to avoid this.

Be aware that with my changes, you will need to trigger on_draw yourself.

https://github.com/adamlwgriffiths/PyGLy/blob/master/pygly/monkey_patch.py

Cheers,

Adam