why does this pyglet code freeze once I add an update() function?

[Andreas]

Hi,

I'm trying to learn pyglet, and I've taken some simple code from [1]
and modified it by basically only adding an "update()" function. No
matter what I actually do in the "update()" function, the program will
always freeze after a random number of iterations. Why is that? Is
there something special about the "update()" function that I need to
consider? If I run the code with the python debugger "python -m pdb
myscript.py" and set a break point in the "update()" function, then
program doesn't freeze. If I delete the break point and let the
program continue it will freeze again eventually. Once the program
freezes in "Pdb" mode, I can not retrieve a traceback.

And here's the code:

import pyglet
from pyglet.gl import *
from ctypes import pointer, sizeof

def triangles_v2f(scale):
if scale < 1.0:
return []
else:
data = triangles_v2f(scale / 2.0)
data.extend([
100 + scale, 100,
100 + scale, 100 + scale,
100, 100 + scale,
])
return data

vbo_id = GLuint()

glGenBuffers(1, pointer(vbo_id))

v2f = triangles_v2f(200)
data = (GLfloat*len(v2f))(*v2f)

glBindBuffer(GL_ARRAY_BUFFER, vbo_id)
glBufferData(GL_ARRAY_BUFFER, sizeof(data), data, GL_STATIC_DRAW)

window = pyglet.window.Window(width=400, height=400)
fps_display = pyglet.clock.ClockDisplay()
glClearColor(0.2, 0.4, 0.5, 1.0)
glEnableClientState(GL_VERTEX_ARRAY)


counter = 0;
def update(dt):
global counter
counter += 1
# print counter
pyglet.clock.schedule_interval(update, 1.0/60.0)


@window.event
def on_draw():
glClear(GL_COLOR_BUFFER_BIT)

glColor3f(0, 0, 0)

glBindBuffer(GL_ARRAY_BUFFER, vbo_id)
glVertexPointer(2, GL_FLOAT, 0, 0)

glDrawArrays(GL_TRIANGLES, 0, len(v2f)/2)
fps_display.draw()


pyglet.app.run()


any pointers on how to track down and fix this problem are greatly
appreciated!
cheers,
andreas

ps: I am using a recent version of pyglet 1.2dev on a linux machine
[1]: https://sites.google.com/site/swinesmallpygletexamples/vbo-triangle

[Михаил Сидоров]

I have the same problem under Ubuntu though the same code works nice under Arch Linux and Windows on the same machine. If you use Ubuntu it is likely to be another Ubuntu-specific bug.

2012/3/15 Andreas <andreas....@gmail.com>

--
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.

[Andreas]

Hi Mikhail,

On Mar 15, 11:33 am, Михаил Сидоров <pevz...@gmail.com> wrote:
> I have the same problem under Ubuntu though the same code works nice under
> Arch Linux and Windows on the same machine. If you use Ubuntu it is likely
> to be another Ubuntu-specific bug.

thanks for the quick reply! did you maybe figure out how to catch
these kind of Ubuntu specific freezes? or how to prevent them from
happening in the beginning?

cheers,
andreas

[Михаил Сидоров]

Unfortunately I have no idea at all, sorry.

2012/3/15 Andreas <andreas....@gmail.com>

[Charles Brandt]

I've been using pyglet trunk (1.2 dev) on a Mac with OS X version 10.6.8
and Python version 2.6.1. Generally, things seem to be working very
well with the Cocoa version of pyglet.

I have noticed one strange behavior when trying to display a PNG file.
For example, using the following image:
http://i.imgur.com/65CT3.png

With:
python pyglet/examples/image_display.py 65CT3.png

results in a very dim version of the image being displayed. It almost
looks like a black image with nothing there, but the original version is
faintly visible. It seems to be specific to the PNG format (maybe a
transparency issue?), since a JPG version of the image shows up no
problem. Also, I have tried the same PNG on other back ends with pyglet
(windows, etc) and the image shows up as expected.

Any ideas?

Thanks!

-Charles.

[Phillip Nguyen]

I think this is probably a bug in pyglet's quartz image decoder having
to do with loading color-indexed PNGs.

--phillip

[Nathan]

I have run into that same problem on OS X! 8-bit PNG files come out
wildly distorted color-wise (in my case, a picture with muted colors
came out in bright blues). I just figured 8-bit PNG wasn't supported
and switched to 24-bit, though the file sizes tend to be larger.

~ Nathan

[Phillip Nguyen]

I just pushed a change which I think fixes this in the trunk. I
formerly had been trying to be clever about dealing with different
data formats and it seems like it backfired. So now image data is
loaded in as RGBA regardless of its original format, which I think
more closely agrees with what the other platforms do. The upshot is
that indexed color PNGs should now load properly and I think some
other issues were cleared up as well.

--phillip

[Phillip Nguyen]

One more quick note:

The quartz image loader now automatically loads in images with
premultiplied alpha by default. There doesn't seem to be any easy way
around this. So this means that you should use the correct blending
function for premultiplied alpha, which is

glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA)

or if using the sprite module, set your sprite's blend_src to GL_ONE.

Otherwise, you'll end up with dark fringes around your images.

--phillip

[Tristam MacDonald]

On Sat, Mar 17, 2012 at 3:33 PM, Phillip Nguyen <evil.p...@gmail.com> wrote:

One more quick note:

The quartz image loader now automatically loads in images with
premultiplied alpha by default.  There doesn't seem to be any easy way
around this.  So this means that you should use the correct blending
function for premultiplied alpha, which is

glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA)

or if using the sprite module, set your sprite's blend_src to GL_ONE.

Otherwise, you'll end up with dark fringes around your images.

--phillip

What are peoples thoughts are normalising this by making pre-multiplied alpha the default for loaders on all platforms?

It seems like a win-win to me.

--

Tristam MacDonald

System Administrator, Suffolk University Math & CS Department

http://swiftcoder.wordpress.com/

[Greg Ewing]

Tristam MacDonald wrote:

> What are peoples thoughts are normalising this by making pre-multiplied
> alpha the default for loaders on all platforms?

Whatever behaviour is chosen, it should definitely be the
same on all platforms.

--
Greg

[Nathan]

Well, I don't have any objections. But then, I don't really know much
about OpenGL. :-)

~ Nathan

[Andreas Schiefer]

swiftcoder wrote:

> What are peoples thoughts are normalising this by making pre-multiplied 

> alpha the default for loaders on all platforms?

I think it would be reasonable to do so. For one because, as Greg has pointed out, 

it should be definitly consistent across platforms. And it also seems to be a better

default behaviour, provided that things like Sprite blend_src etc. will default to GL_ONE

then.

[Greg Ewing]

Andreas Schiefer wrote:
> And [premultiplied alpha] also seems to be a better default behaviour,

I'm inclined to agree. You can do everything with premultiplied
alpha that you can do with non-premultiplied, and more besides.
For example, you can overlay fire or glow effects that add light
without darkening what's behind.

--
Greg

[Andreas Kotowicz]

quick update for reference:

downgrading nvidia drivers from version 295 to 280 fixed the problem.
However, this only works with the latest pyglet dev version - if you
have the python-pyglet package installed that ships with ubuntu, the
program will still freeze.

andreas

2012/3/15 Михаил Сидоров <pev...@gmail.com>: