Just to report that I was having this same problem (any pyglet program
would hang after some time) in Kubuntu 13.10 running linux 64 bits with an
NVidia GTX650 card and NVidia driver 304.88. The suggestion given by Jan
Ciger, adding vsync=False like "window = pyglet.window.Window(vsync=False,
...)", works for me, as well as the suggestion of Jeff Jahr of disabling
sync to vblank in the nvidia X server settings application. The latter one
seems to be better since you don't have to change the code.
Hermano
On Thursday, October 31, 2013 6:44:33 PM UTC-3, John Ladasky wrote:
>
> Hi folks,
>
> I'm continuing to work with Pyglet, and I'm getting results, but also
> problems. Here is a simple application which I developed first on my
> Ubuntu Linux 13.04 system, 64-bit version, AMD CPU, running Python 3.3.2
> and pyglet 1.2alpha1. This is a "hello world" program, with Earth as a
> bouncing ball in the background.
>
> ===================================================================
>
> import pyglet
> from random import uniform, choice
>
> def random_velocity():
> return [choice((-1,1)) * uniform(0.25,0.75) for x in range(2)]
>
> class MyWindow(pyglet.window.Window):
>
> def __init__(self, *args, **kwargs):
> super().__init__(*args, **kwargs)
> self.label = pyglet.text.Label(
> 'Hello, crazy world!',
> font_name='Times New Roman',
> font_size=40,
> x = self.width//2, y = self.height//3,
> anchor_x='center', anchor_y='center')
> img = pyglet.resource.image('Earth 99x99.png')
> self.sprite = pyglet.sprite.Sprite(
> img,
> x = (self.width - img.width)//2,
> y = 2*self.height//3 - img.height//2)
> self.sprite.vx, self.sprite.vy = random_velocity()
> # Bounce boundaries
> self.left = 5
> self.right = self.width - img.width - 5
> self.bottom = 5
> self.top = self.height - img.height - 5
> # Animation clock
> pyglet.clock.schedule_interval(self.update, 1 / 60.0)
>
> def on_draw(self):
> self.clear()
> self.sprite.draw()
> self.label.draw()
>
> def update(self, dt):
> sp = self.sprite
> sp.x += sp.vx
> sp.y += sp.vy
> if sp.x < self.left or sp.x > self.right:
> sp.vx = -sp.vx
> if sp.y < self.bottom or sp.y > self.top:
> sp.vy = -sp.vy
> sp.draw()
>
> MyWindow()
> pyglet.app.run()
>
>
> ===================================================================
>
> It runs for a while, but then it hangs. The bouncing-ball Earth simply
> stops moving. Attempting to use the mouse to close the Pyglet window
> fails. The only way that I have found to close the window is to kill the
> Python interpreter which is running it. CPU loading is light while the
> animation is running, but drops to zero once the animation stops. It is as
> if the Pyglet clock that I defined simply stopped ticking.
>
> I added some timing features to the program (not shown) and ran it about a
> dozen times. The program never crashed in less than 33 seconds, no matter
> what else I was doing with the computer while it ran (switching to my IDE,
> reading my web browser, etc.). Quite a few crashes occurred quite close to
> that 33-second mark. The longest I got the program to run without crashing
> was 229 seconds. And while I can't be sure of this, in a few instances it
> appeared that the crashes were correlated with a mouse event. It looked
> like the animation stopped right as I clicked into, or away from, my Pyglet
> application window.
>
> Out of curiosity, I tried my application on my Windows Vista virtual
> machine, running under VirtualBox. It's only the 32-bit version of Vista,
> but I am still using Python 3.3.2 and pyglet1.2alpha1. My program didn't
> crash -- good! But it ran sluggishly, probably because I was generating a
> huge and repeating list of OpenGL warnings. A quick Internet search
> revealed that VirtualBox has some OpenGL bugs that are being fixed. This
> suggested two things to me: 1) that Pyglet programs may have different
> behaviors on different operating systems, and 2) that a VirtualBox might
> not be the best place to investigate these problems.
>
> So then I tried a Windows 7 system running directly on the hardware, not
> in a virtual machine. I'm back to a 64-bit version of the OS here. But as
> before, I have not changed any of the other variables. I stuck with Python
> 3.3.2 and pyglet1.2alpha1. My program didn't crash. I got no OpenGL
> warning messages. Everything ran flawlessly for multiple runs, exceeding
> 10 minutes each.
>
> So, I can't be certain that my program reveals a problem with Pyglet
> itself. It may have something to do with something on which Pyglet depends
> -- for example, the implementations of OpenGL on my various systems. How
> would I know? Is there anything that I can address or repair? Any advice
> is appreciated. Thanks!
>
>
--
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.
