Hi all,
glumpy is a fast OpenGL visualization tool for numpy arrays coded on top of pyglet (http://www.pyglet.org/). The package contains many demos showing basic usage as well as integration with matplotlib. As a reference, the animation script available from matplotlib distribution runs at around 500 fps using glumpy instead of 30 fps on my machine.
Package/screenshots/explanations at: http://www.loria.fr/~rougier/coding/glumpy.html
(it does not require installation so you can run demos from within the glumpy directory).
Nicolas
Hi Nicolas,
This is technically called OpenGL backend, isn’t it? It is nice that integrates with matplotlib, however 300 hundred lines of code indeed a lot of lines for an ordinary user. Do you think this could be further integrated into matplotlib with a wrapper to simplify its usage?
···
On Mon, Sep 28, 2009 at 9:06 AM, Nicolas Rougier <Nicolas.Rougier@…2073…> wrote:
Hi all,
glumpy is a fast OpenGL visualization tool for numpy arrays coded on
top of pyglet (http://www.pyglet.org/). The package contains many
demos showing basic usage as well as integration with matplotlib. As a
reference, the animation script available from matplotlib distribution
runs at around 500 fps using glumpy instead of 30 fps on my machine.
Package/screenshots/explanations at: http://www.loria.fr/~rougier/coding/glumpy.html
(it does not require installation so you can run demos from within the
glumpy directory).
Nicolas
NumPy-Discussion mailing list
NumPy-Discussion@…177…
http://mail.scipy.org/mailman/listinfo/numpy-discussion
–
Gökhan
Well, I’ve been starting working on a pyglet backend but it is currently painfully slow mainly because I do not know enough of the matplotlib internal machinery to really benefit from it. In the case of glumpy, the use of texture object for representing 2d arrays is a real speed boost since interpolation/colormap/heightmap is made on the GPU.
Concerning matplotlib examples, the use of glumpy should be actually two lines of code:
from pylab import *
from glumpy import imshow, show
but I did not package it this way yet (that is easy however).
I guess the main question is whether people are interested in glumpy to have a quick & dirty “debug” tool on top of matplotlib or whether they prefer a full fledged and fast pyglet/OpenGL backend (which is really harder).
Nicolas
···
On 28 Sep, 2009, at 18:05 , Gökhan Sever wrote:
On Mon, Sep 28, 2009 at 9:06 AM, Nicolas Rougier <Nicolas.Rougier@…2073…> wrote:
Hi all,
glumpy is a fast OpenGL visualization tool for numpy arrays coded on
top of pyglet (http://www.pyglet.org/). The package contains many
demos showing basic usage as well as integration with matplotlib. As a
reference, the animation script available from matplotlib distribution
runs at around 500 fps using glumpy instead of 30 fps on my machine.
Package/screenshots/explanations at: http://www.loria.fr/~rougier/coding/glumpy.html
(it does not require installation so you can run demos from within the
glumpy directory).
Nicolas
NumPy-Discussion mailing list
NumPy-Discussion@…878…177…
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi Nicolas,
This is technically called OpenGL backend, isn’t it? It is nice that integrates with matplotlib, however 300 hundred lines of code indeed a lot of lines for an ordinary user. Do you think this could be further integrated into matplotlib with a wrapper to simplify its usage?
–
Gökhan
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options
Gökhan Sever wrote:
This is technically called OpenGL backend, isn't it?
well, I think it's different -- he's not really using the standard backend API.
The trick with doing a real OpenGL back-end, is that a lot of computation time is spend doing transforms, and that can't be fully pushed to the back-end, because MPL provided arbitrary transforms.
There is also a fair bi tof time spent pushing data to the back-end.
I think to really get the benefit of OpenGL, you'd need the back-end to be semi-perstent -- you'd pass data in, and teh back-end would render it without having to pass the data in again. This would only support transforms that the back-end supports (linear only?). However, I think there could still be areal performance benefit bey breaking the transform pipeline into two parts -- one from arbitrary coordinates to something orthogonal and linear, and then a final one from that to screen coordinates (zooming and panning). Then you'd at least get full hardware accelerated performance for zooming and panning
We're doing this for a high-performance interactive mapping app, and it's working pretty well. However, OpenGL is pretty darn low-level, so there's a lot of code to write!
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@...259...