Hi Fernando,

...

It's quite hackable, too -- I rigged up a very simple system to run pyglet windows in a background thread, so I could control the microscope from an interactive python interpreter, while still being able to programmatically interact with pyglet window objects. (Happy to share this code with anyone who desires. It's much cleaner, IMO, than the gyrations that ipython has to go through to support nonblocking QT, Tk, etc. windows. This is becase the pyglet mainloop is in python, and is easy to subclass and otherwise mess with.)

Does your code work as-is inside ipython? Would you want to contribute it to ipython? We'd love to ship an out-of-the-box-pyglet-shell, just let us know.

I'd be happy to provide this code. There are a few caveats to its use, though -- perhaps you could help me come up with an easier interface. Out of the box, pyglet ships with a main-loop that uses platform- specific code to sleep until a GUI event happens, or after a certain time elapses (to enforce a user-specified minimum framerate). Every time the loop wakes up, it sends repaint (in pyglet: on_draw) events to all of the windows. Now, Pyglet works fine if all the calls to it are made from one thread only. So what I do is run a subclass of the default event loop in a background thread. This subclassed event loop checks a "message queue" (basically, a list of callback functions) every time it wakes up, and if the queue is non-empty, calls a few of the callbacks. This way, code that calls pyglet functions can be added to the message queue so that it will be called in the context of the pyglet thread. (I've added a few bells and whistles, like proxy objects that "look" like pyglet windows, but route method calls and getattr/setattr through the event loop, so that interaction is seamless.) Here comes the caveat, though: to keep latency down for tending the message queue, the main loop needs to wake up frequently (at least 20 Hz). However, sending repaint events to every window that often is pretty inefficient in most cases. So I elected to not send the repaint events by default. Instead, a pyglet window needs to call it's on_draw method after every event that requires a redraw (e.g. a clock tick, a GUI interaction). This sort of event loop is a more efficient than the default pyglet loop in general, but unfortunately, the coding style is a bit different. As such, my code doesn't work with any old pyglet window class out of the box -- some very minor changes need to be made. I could perhaps fix things so this isn't necessary -- figure out a way for the main-loop to distinguish between being awoken to tend the message queue, and being awoken on GUI events or for "minimum framerate" reasons. But perhaps the issue is un-fixable... Another caveat is that this approach is almost completely backwards to that taken by the rest of the interactive windowing code in ipython. (That code essentially feeds an embedded python interpreter, which runs as a callback from the GIU mainloop, line-by-line input from stdin.) As such, my code might be a bit out-of-place and harder to maintain. I suspect that the original ipython approach will work fine for pyglet too, and perhaps without the above caveat; however it might be a bit more processor-intensive. Zach

On Aug 26, 2008, at 7:25 PM, Zachary Pincus wrote:

Another option, depending on how much plumbing you're interested in, is to write a custom tool with OpenGL...

I've been using Pyglet for some rather-specialized data display needs (blit live video from a microscope + plot derived measures on top of the video, using the mouse to pan and zoom), and it's pretty nice. Basically, Pyglet is a (pretty simple) pure-python, ctypes-based, multiplatform interface to OpenGL, windowing, and mouse/keyboard IO. It's quite hackable, too -- I rigged up a very simple system to run pyglet windows in a background thread, so I could control the microscope from an interactive python interpreter, while still being able to programmatically interact with pyglet window objects. (Happy to share this code with anyone who desires. It's much cleaner, IMO, than the gyrations that ipython has to go through to support nonblocking QT, Tk, etc. windows. This is becase the pyglet mainloop is in python, and is easy to subclass and otherwise mess with.)

The downside is of course that OpenGL isn't a plotting library. The upside is that if you have a well-defined plotting task, and you want full aesthetic control and also high speed, you can get that with not too much work.

Just a thought, Zach

Hey Zach, I've been working on an early version of an OpenGL/pyglet-based backend for Chaco. It currently does most of the plots that are supported in Chaco (although there are issues with the color bar rendering incorrectly). I use pyglet to get a window and provide an platform independent API for events, but most of the actual drawing is done via a C++ GraphicsContext class that makes calls to libOpenGl. (I use pyglet to render text and Andrew Straw's pygarrayimage to draw images.) This GraphicsContext has a transform stack, a clip stack, supports compiled paths, etc. I also have my own little "PygletSimpleApp" class analog of WxSimpleApp and whatnot. It is indeed very nice to have total control over the event loop - so much simpler than fiddling with the Wx event queue! I've tested my code on win32, Ubuntu 7, and OS X. The beauty of doing it this way is that I can reuse all of the data handling and rendering code from Chaco, and on systems where I have WX or Qt available, I can switch to using those instead of Pyglet by setting a single environment variable. I'm hoping to get this GL backend polished up enough to release it as a supported part of Chaco, maybe by the next large-ish release (3.1? 3.2?). -Peter

On Aug 28, 2008, at 4:49 PM, Bryan Cole wrote:

The GL backend for Chaco is an exciting development. Althought the examples worked fine with the pyglet backend, when I tried to experiment with it I couldn't see how to use it within the context of a full TraitsUI/wx application. Pyglet doesn't seem to integrate with any other toolkit event loop.

Yep, there be the dragons. I started working on this late Tuesday night but haven't finished it yet. It is certainly possible to do, it's just that my test code is still doing funky things. :) The goal that Stefan and I were talking about is to embed a Pyglet-based CoverFlow into a Traits UI editor. (My personal goal is to then stick live Chaco plots on the CoverFlow covers. ;)

Can the gl_graphics_context be "dropped in" in place of the standard agg gc? Is there an easy switch to set this up?

You can set the KIVA_WISHLIST environment variable to "gl", and then subsequent imports of GraphicsContext from enthought.kiva will use the GC from backend_gl.py. This doesn't get you nice event handling through Enable, but it does work. You can also directly import the graphics context and play with it: from enthought.kiva.backend_gl import GraphicsContext from enthought.kiva import Font from pyglet import clock, window def main(): clock.set_fps_limit(60) win = window.Window() win.set_size(480, 320) win.set_caption("Backend GL + Pyglet") gc = GraphicsContext((480, 320)) gc.gl_init() exit = False while not exit: win.dispatch_events() gc.clear() gc.set_stroke_color((1, 0, 0, 1)) gc.set_line_width(2) gc.rect(100, 100, 200, 75) gc.stroke_path() gc.set_fill_color((0,0,1,1)) font = Font("Arial", 48) gc.set_font(font) gc.show_text_at_point("Kiva GL!", 110, 110) win.flip() clock.tick() if win.has_exit: exit = True return if __name__ == "__main__": main() -Peter