Thomas Schreiner wrote: > If we do so by calling p.go() from inside a python > thread, the start frame of the graphical presentation is displayed but > is not updating at all. That's not surprising -- it sounds like you've setup OpenGL from the main thread but are then calling it from another thread. I think (but I'm not completely sure) that OpenGL implementations are generally not able to be called this way. You'd have to setup the VE entirely from the second thread. If we call p.go() from the main part of the > program and leave out threading, it works perfectly, but it blocks our > other python threads - they just don't run. This is somewhat surprising to me, but I have some ideas. Firstly, is the VE running without vsync? If so, it could be running full out, drawing thousands of frames per second and dominating the CPU. (With the Python GIL, this probably wouldn't be helped by having a multi-core system.) Secondly, it is entirely possible that the call to swap_buffers() is not releasing the GIL. So, even though the CPU is doing nothing, your other Python thread is prevented from running. If this is the case, we need to figure out how to release the GIL. (Not hard but will require modifying the C code that runs at that point.) If the issue is one of these 2 possibilities, the test will be whether the CPU is maxed out. Are you using PyOpenGL 2 (SWIG-based) or 3 (ctypes-based)? BTW, I've done just what I understand you want to do quite well with only a single thread -- typically between frame draws I query the data acquisition buffer, which is big enough to accommodate the data coming in. Without vsync on and with a simple visual stimulus, I can query the card and redraw the frames on the order of 1000 fps with a 1.5 GHz Celeron computer. In this configuration, I've found it easier to use the VE without the FlowControl module. Cheers! Andrew ====================================== The Vision Egg mailing list Archives: //www.freelists.org/archives/visionegg Website: http://www.visionegg.org/mailinglist.html