That does not seem very compatible with the way backends appear to work then. I fear that in order to have an efficient GL backend, either this backend system would need to be updated so that it can be directly connected to transformation events, or one would need to get around the backend system.
Anyway, it looks like the difficulty would come more from the matplotlib backend system than the OpenGL part (by the way, your rendering demos are really cool Nicolas!). It would be great if a GSoC student could work on this, and I would be happy to help if necessary. In the meantime, I might write sometime an extremely basic high-level matplotlib-like interface for Galry, with support in particular for scatter plots, continuous-time signals, textures, maybe other plot types if anyone asks. It may be useful until a fully working GL backend becomes available.
Yep, I’m still developing some OpenGL technics to provide both nice and fast rendering and I hope to be able to help the writing of a GL backend for matplotlib next summer (provided we get a GSoC student for the project).
So far, my main concern is that for efficient rendering using OpenGL, you need to consider that drawing means to create objects on the graphic card (line, curve, image, points, etc) that can be later manipulated (scaling/rotating/coloring/properties change, etc.). From what I remember in my early attempts at writing an OpenGL backend, I did not find the proper way to enforce such framework. Said differently, the backend is supposed to implement drawing operations while I would need to know if the drawing operations actually relates to something that is already on the graphic card or not. I’m not sure I’m very clear but I can develop the point if necessary. Having read the post by Michael (http://mdboom.github.com/blog/2012/08/06/matplotlib-client-side/) on client-side rendering, I think the proposed three-way split might be a solution but I do not know how advanced are the ideas.
To date, I’ve been working on different things:
Text/font : http://code.google.com/p/freetype-gl/ (c code)
Stroke/dash/paths: http://code.google.com/p/gl-agg/ (python)
Images: http://code.google.com/p/glumpy/ (python)
If you want to get a feel of how nice and fast rendering could be, have a look at ‘demo-lines.py’ from the gl-agg repository (and play with mouse). From these experiments, I think it is possible to achieve AGG quality using OpenGL. What is really exciting is the perspective of having a opengl/webgl backend that could be used with ipython (there has been a recent post on ipython list that show such integration for a molecule viewer).
Anyway, you’re more than welcome to contribute to glumpy, but in the long run, I hope it will disappear in favor of a matplolib GL backend.
Nicolas
On Nov 15, 2012, at 22:03 , Benjamin Root wrote:
On Thu, Nov 15, 2012 at 2:24 PM, Cyrille Rossant <cyrille.rossant@…149…> wrote:
Hi all,
I am developing a high-performance interactive visualization package in Python based on PyOpenGL (http://rossant.github.com/galry/). It is primarily meant to be used as a framework for developing complex interactive GUIs (in QT) that deal with very large amounts of data (tens of millions of points). But it may also be used, like matplotlib, as a high-level interactive library to plot and visualize data.
The low-level interface is mostly done at this point (the code is still in an experimental stage though), and I’m now focusing on my current research project which is to write a scientific GUI based on this interface. However, I think people (including myself!) may be interested in a matplotlib-like high-level interface. I was first thinking about writing such an interface from scratch, by implementing a very small fraction of the matplotlib interface (basic commands like figure(), plot(), subplot(), show(), etc.). One could then quickly visualize huge datasets with the same commands than matplotlib.
Another solution would be to write a matplotlib backend based on this library. I am not familar enough with the internals of matplotlib to know how complicated it could be. I may do it myself, but it would probably take a long time since it is currently not my highest priority. I would be glad if someone experienced in writing backends was interested in working on it. Actually I could do everything that is specific to my library, which already provides commands to plot points, lines, textures, etc. The canvas is based on QT and may be similar to what is already implemented in the QT backend.
Of course, it would already be great if only the most basic plotting features were available in the backend. A first step could be for example to have a simplistic example “plot(x, sin(x))” working (with interactive navigation).
I am looking forward to your feedback.
Best,
Cyrille Rossant
Great to hear another person interested in bringing opengl to matplotlib! Another project you might be interested in collaborating with is Glumpy: http://code.google.com/p/glumpy/
From my limited knowledge of OpenGL, what my vision is that any of the existing backends have support for an OpenGL object, so we just need to be able to instantiate the opengl object in any figure object, and know how to send it the appropriate commands and data. So, it is not exactly a backend, more of a “middling”. Anyway, I think the dev at Glumpy would be happy to have help, and probably have much more developed ideas on how to integrate with matplotlib.
Cheers!
Ben Root
