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: //www.freelists.org/archives/visionegg Website: http://www.visionegg.org/mailinglist.html
