On RHEL4, I get the following message: This OpenGL does not support framebuffer objects I understand that I'm probably just suffering from a relatively old Mesa/OpenGL stack here. And obviously, just because some older systems won't support this is not a reason to not include it as an optional backend. Can you possibly send a screen shot to the list for those of us who can't see it? Is the quadmesh interpolated? That would be a huge improvement over anything we can do currently. As for developing a full OpenGL backend, note that the process of writing a backend has been greatly simplified as of 0.98.x (there's only about four rendering methods to implement now, with three more optional ones to re-implement for performance reasons). You can start by looking at backend_bases.py. I'm happy to help with any questions you have as you go along, but as I don't have a working pyglet/OpenGL, I can't be of much help for testing. Cheers, Mike Ryan May wrote: > Paul Kienzle wrote: > >> Hi, >> >> There was a recent discussion about opengl and matplotlib in the >> context of matplotlib rendering speeds. >> >> At the scipy sprints we put together a proof of concept renderer >> for quad meshes using the opengl frame buffer object, which we >> then render as a matplotlib image. Once the data is massaged >> to the correct form we were seeing rendering speeds of about >> 10 million quads per second. See below. >> >> Using this technique we can get the advantage of opengl without >> having to write a full backend. Please let me know if you have >> time to contribute to writing a more complete backend. >> > > I know that I (as the other contributer :) ) plan on making this into a > full backend provided: > > 1) The quadmesh code can be shown yield the gains when integrated into > matplotlib more fully > > 2) I find the time (which is a matter of *when*, not if) > > I'm certainly finding thus far that pyglet makes it a lot easier to do a > full backend than some of the other python->opengl methods I'd explored > in the past. > > Ryan > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA