OpenGL backend and pyglet expertiments

Hello,

While looking at possible solutions for a matplotlib OpenGL backend,
I've been experimenting with pyglet (that has no dependencies) and coded
a terminal with embedded 2d arrays display.

Sources & screenshots are available at:
http://www.loria.fr/~rougier/glnumpy.html

Since pyglet seems mature enough, I would like to know if anyone
interested in helping writing the OpenGL backend (using pyglet) ?

Nicolas

The idea of a shell with inline plots is a fascinating one - I like
the minimalism and directness of being able to plot data like this.
And the speed of OpenGL is obviously attractive.

Is the figure() call syntax different from the existing syntax for
figure()? I think there's a usage pattern ingrained in my head that
says 'figure => new window,' and any change to the call syntax for
figure would seem to open up a lot of room for confusion.

It seems that the backend and the shell might be separate issues? My
view of the backends is that they only deal with knowing how to draw
artists, and are separate from the process of creating those artists
through an interactive shell.

The following old thread is also relevant, which you may have already seen:
http://www.nabble.com/opengl-backend-td19192625.html

Thanks,
Eric B

···

On Fri, Apr 3, 2009 at 7:17 AM, Nicolas Rougier <Nicolas.Rougier@...466...> wrote:

Hello,

While looking at possible solutions for a matplotlib OpenGL backend,
I've been experimenting with pyglet (that has no dependencies) and coded
a terminal with embedded 2d arrays display.

Sources & screenshots are available at:
http://www.loria.fr/~rougier/glnumpy.html

Since pyglet seems mature enough, I would like to know if anyone
interested in helping writing the OpenGL backend (using pyglet) ?

Nicolas

------------------------------------------------------------------------------
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi,

I agree, shell with inline plot is a different issue. I mainly coded it as a proof a concept and because I find it useful for my own needs.

The figure call is quite different from the figure call of matplotlib, only the name is common.
The idea was to be able to describe a configuration of arrays with a minimum amount of code.

figure(Z) -> plot Z
figure([Z1,Z2]) -> plot Z1,Z2 side by side
figure([[Z1,Z2], [Z3,Z4]]) -> plot Z1,Z2 side by side and below, Z3,Z4 side by side

You can optionally indicate that an array spans several rows or columns:

figure([[Z1,'-'],
       [Z3,Z4]]) -> plot Z1 on two columns and below, Z3,Z4 side by side
figure([[Z1,Z2],
       ['|', Z4]]) -> plot Z1 on two rows, then Z2 on first line and Z4 on second line.

I looked at the thread you're talking about and it was the reason in the first place that I investigated pyglet.
My approach is a bit different since I use a texture and a single quad to render it, it makes things quite fast. The mapping from a float array to a texture data is pretty efficient using numpy interface and it allows me to continuously update texture data (just try modifying the array from within the console).

Nicolas

···

On 3 Apr, 2009, at 17:12 , Eric Bruning wrote:

The idea of a shell with inline plots is a fascinating one - I like
the minimalism and directness of being able to plot data like this.
And the speed of OpenGL is obviously attractive.

Is the figure() call syntax different from the existing syntax for
figure()? I think there's a usage pattern ingrained in my head that
says 'figure => new window,' and any change to the call syntax for
figure would seem to open up a lot of room for confusion.

It seems that the backend and the shell might be separate issues? My
view of the backends is that they only deal with knowing how to draw
artists, and are separate from the process of creating those artists
through an interactive shell.

The following old thread is also relevant, which you may have already seen:
http://www.nabble.com/opengl-backend-td19192625.html

Thanks,
Eric B

On Fri, Apr 3, 2009 at 7:17 AM, Nicolas Rougier > <Nicolas.Rougier@...466...> wrote:

Hello,

While looking at possible solutions for a matplotlib OpenGL backend,
I've been experimenting with pyglet (that has no dependencies) and coded
a terminal with embedded 2d arrays display.

Sources & screenshots are available at:
http://www.loria.fr/~rougier/glnumpy.html

Since pyglet seems mature enough, I would like to know if anyone
interested in helping writing the OpenGL backend (using pyglet) ?

Nicolas

------------------------------------------------------------------------------
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Wow, the screenshots look gorgeous!

Unfortunately I tried to run it after installing it in my path and I
got this (same for glnumpy):

uqbar[bin]> ./glpython
Traceback (most recent call last):
  File "./glpython", line 70, in <module>
    logo = pyglet.resource.image('logo.png')
  File "/var/lib/python-support/python2.5/pyglet/resource.py", line
481, in image
    identity = self._cached_images[name] = self._alloc_image(name)
  File "/var/lib/python-support/python2.5/pyglet/resource.py", line
425, in _alloc_image
    file = self.file(name)
  File "/var/lib/python-support/python2.5/pyglet/resource.py", line 383, in file
    raise ResourceNotFoundException(name)
pyglet.resource.ResourceNotFoundException: Resource "logo.png" was not
found on the path. Ensure that the filename has the correct
captialisation.

This is on ubuntu 8.10, 64 bit, installed with --prefix=$HOME/usr/opt.

Cheers,

f

···

On Fri, Apr 3, 2009 at 4:17 AM, Nicolas Rougier <Nicolas.Rougier@...466...> wrote:

Hello,

While looking at possible solutions for a matplotlib OpenGL backend,
I've been experimenting with pyglet (that has no dependencies) and coded
a terminal with embedded 2d arrays display.

Sources & screenshots are available at:
http://www.loria.fr/~rougier/glnumpy.html

Sorry for that, I coded it on linux and just tested on mac.
I fixed the error and upload the new version on the same link. Tell me if it's ok.

Nicolas

···

On 3 Apr, 2009, at 18:55 , Fernando Perez wrote:

On Fri, Apr 3, 2009 at 4:17 AM, Nicolas Rougier > <Nicolas.Rougier@...466...> wrote:

Hello,

While looking at possible solutions for a matplotlib OpenGL backend,
I've been experimenting with pyglet (that has no dependencies) and coded
a terminal with embedded 2d arrays display.

Sources & screenshots are available at:
http://www.loria.fr/~rougier/glnumpy.html

Wow, the screenshots look gorgeous!

Unfortunately I tried to run it after installing it in my path and I
got this (same for glnumpy):

uqbar[bin]> ./glpython
Traceback (most recent call last):
File "./glpython", line 70, in <module>
   logo = pyglet.resource.image('logo.png')
File "/var/lib/python-support/python2.5/pyglet/resource.py", line
481, in image
   identity = self._cached_images[name] = self._alloc_image(name)
File "/var/lib/python-support/python2.5/pyglet/resource.py", line
425, in _alloc_image
   file = self.file(name)
File "/var/lib/python-support/python2.5/pyglet/resource.py", line 383, in file
   raise ResourceNotFoundException(name)
pyglet.resource.ResourceNotFoundException: Resource "logo.png" was not
found on the path. Ensure that the filename has the correct
captialisation.

This is on ubuntu 8.10, 64 bit, installed with --prefix=$HOME/usr/opt.

Cheers,

f

Great!

Would you have any interest in having this be shipped/developed as
part of IPython itself?

You are using a fair amount of internals of the ipython machinery, and
we're getting ready for a large cleanup. Having your code shipped
with ipython itself would give it perhaps more exposure, as well as
allow it to evolve in sync with the rest of the API, since we could
test it as the internals change.

I think it would be great to ship this with ipython itself, and I'm
sure you'd get help and contributions from the rest of the ipython
team as well...

Best,

f

···

On Fri, Apr 3, 2009 at 10:00 AM, Nicolas Rougier <Nicolas.Rougier@...466...> wrote:

Sorry for that, I coded it on linux and just tested on mac.
I fixed the error and upload the new version on the same link. Tell me if
it's ok.

Sure, thread about IPython integration to be continued on ipython-dev list...

Nicolas

···

On 3 Apr, 2009, at 19:07 , Fernando Perez wrote:

On Fri, Apr 3, 2009 at 10:00 AM, Nicolas Rougier > <Nicolas.Rougier@...466...> wrote:

Sorry for that, I coded it on linux and just tested on mac.
I fixed the error and upload the new version on the same link. Tell me if
it's ok.

Great!

Would you have any interest in having this be shipped/developed as
part of IPython itself?

You are using a fair amount of internals of the ipython machinery, and
we're getting ready for a large cleanup. Having your code shipped
with ipython itself would give it perhaps more exposure, as well as
allow it to evolve in sync with the rest of the API, since we could
test it as the internals change.

I think it would be great to ship this with ipython itself, and I'm
sure you'd get help and contributions from the rest of the ipython
team as well...

Best,

f

Eric Bruning wrote:

The idea of a shell with inline plots is a fascinating one -

Then check out reinteract -- very cool:

http://www.reinteract.org/trac/

(though no opengl)

-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@...236...

There is also:
http://www.loria.fr/~rougier/pycons.html

which is a gtk shell with embedded matplotlib figures.

Nicolas

···

On 5 Apr, 2009, at 06:02 , Christopher Barker wrote:

Eric Bruning wrote:

The idea of a shell with inline plots is a fascinating one -

Then check out reinteract -- very cool:

http://www.reinteract.org/trac/

(though no opengl)

-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@...236...

------------------------------------------------------------------------------
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

There has been a recent thread discussing sympy interface to pyglet in the context of matplotlib refactoring of the 3D code. See thread named 'Updating MPlot3D to a more recent matplotlib.'
If you are porting pyglet interface to Ipython, Ondrej might be happy to see his sympy 3D plotting routines go there as well :slight_smile:
cheers,
Johann

Nicolas Rougier wrote:

···

Sure, thread about IPython integration to be continued on ipython-dev list...

Nicolas

On 3 Apr, 2009, at 19:07 , Fernando Perez wrote:

On Fri, Apr 3, 2009 at 10:00 AM, Nicolas Rougier >> <Nicolas.Rougier@...466...> wrote:
    

Sorry for that, I coded it on linux and just tested on mac.
I fixed the error and upload the new version on the same link. Tell me if
it's ok.
      

Great!

Would you have any interest in having this be shipped/developed as
part of IPython itself?

You are using a fair amount of internals of the ipython machinery, and
we're getting ready for a large cleanup. Having your code shipped
with ipython itself would give it perhaps more exposure, as well as
allow it to evolve in sync with the rest of the API, since we could
test it as the internals change.

I think it would be great to ship this with ipython itself, and I'm
sure you'd get help and contributions from the rest of the ipython
team as well...

Best,

f
    
------------------------------------------------------------------------------
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel