[visionegg] Re: pyglet vs. pygame

My guess is that the OpenGL calls are not thread-safe, nor is the window-manager interaction (including events), but if we call OpenGL only in one thread and window manager stuff in another, things should be fine. The primary points of interaction would be stuff like resizing windows, but that could be handled in a thread-safe way, I think.
BTW, one idea for VE2, which is nothing but a couple of ideas at this point, would be to shift all drawing (OpenGL calls) to a 2nd thread running in the background so that the user's thread could just do stuff like: 
  draw_1Hz_grating()
  sleep(10) # the grating keeps moving
  clear_display()
In fact, even better would be if the rendering thread didn't even need the Python global interpreter lock (GIL) so that, theoretically, the rest of the script would be completely free to do whatever it liked, including hog the GIL (and therefore could be easily used by people with no understanding of the GIL). This would probably require this drawing thread to be implemented in C, which to me seems is the worst downside apart from coming up with a reasonable API. 

Cheers!
Andrew

Eamon Caddigan wrote:
This looks interesting! I like the way event handling seems to take place. However, I wonder if it's thread-safe?
I recently wrote an extension of VisionEgg.FlowControl.Presentation that spawns a separate thread for processing the event queue (otherwise, reaction time measurements are a function of refresh rate). With events being members of pyglet window objects (as opposed to being pulled out of a global event queue), it seems like it might be tricky to keep things thread-safe. What do you folks think?
Only a few key VisionEgg components rely on pygame, so it should be possible to extend those to use pyglet instead. VisionEgg.Core.Screen seems to be a good place to start. 

-Eamon


On Dec 20, 2007, at 6:32 PM, Martin Spacek wrote:
I recently stumbled across what sounds like a great replacement for pygame: 

http://pyglet.org/
It's pure python (plus ctypes) and doesn't rely on SDL. It can easily create multiple windows on multiple monitors, and works with OpenGL and (apparently) PyOpenGL.
I see from some of the postings on pyglet's mailing list that Andrew Straw already knows about it.
I'd like to be able to draw the same stimuli with visionegg to two separate pyglet windows on two separate screens. Would it be hard to modify visionegg's Viewport class to accept pyglet screens/displays in place of pygame's SDL screen? I'd be willing to help out, but I'd need guidance. 


======================================
The Vision Egg mailing list
Archives: http://www.freelists.org/archives/visionegg
Website: http://www.visionegg.org/mailinglist.html


======================================
The Vision Egg mailing list
Archives: http://www.freelists.org/archives/visionegg
Website: http://www.visionegg.org/mailinglist.html

Other related posts: