matplotlib-devel Mailing List for matplotlib (Page 5)

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 :)
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
>> <Nic...@lo...> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

> -----Original Message-----
> From: Jouni K. Seppänen [mailto:jk...@ik...]
> Sent: 6 Apr 2009 1:20 PM
> To: mat...@li...
> Subject: Re: [matplotlib-devel] cannot use some fonts on pdf, ps,eps
> backends
> 
> "Andrew Hawryluk" <HA...@no...> writes:
> 
> > When I use Arial Unicode MS within matplotlib, it cannot save to any
> > PostScript-based formats (pdf, eps, ps). Apparently, the font has no
> > glyph names:
> [...]
> >     glyph_name = font.get_glyph_name(gind)
> > RuntimeError: Face has no glyph names

 
> What version of Freetype do you have - does updating it help? The check
> for glyph names is just a call to a Freetype macro

I am using the most recent windows binary (0.98.5.2), so I'm guessing that my Freetype library came bundled inside it.
 
> Does it help if you set ps.fonttype and pdf.fonttype to 42 in
> matplotlibrc?

Yes, that works very well, thanks! However, it now embeds the entire font rather than a subset. This results in a PDF of 14.4 MB with this font. I ran it through ghostscript to get a PDF of 24.2 kB with subsetting, but I'm wondering if I can get subsetting of type 42 fonts directly from matplotlib?

Thanks again,

Andrew

"Andrew Hawryluk" <HA...@no...> writes:

> When I use Arial Unicode MS within matplotlib, it cannot save to any
> PostScript-based formats (pdf, eps, ps). Apparently, the font has no
> glyph names:
[...]
>     glyph_name = font.get_glyph_name(gind)
> RuntimeError: Face has no glyph names
[...]
> I know that these fonts can be included in PDFs, because I can do it
> in other programs.

What version of Freetype do you have - does updating it help? The check
for glyph names is just a call to a Freetype macro:

  if (!FT_HAS_GLYPH_NAMES(face))
    throw Py::RuntimeError("Face has no glyph names");

Does it help if you set ps.fonttype and pdf.fonttype to 42 in
matplotlibrc? If not, could you send me (off-list) a sample of a PDF
file produced by another program using the font, preferably one that
displays the exact same string that causes this problem with matplotlib?

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

When I use Arial Unicode MS within matplotlib, it cannot save to any
PostScript-based formats (pdf, eps, ps). Apparently, the font has no
glyph names:

Traceback (most recent call last):
  File "G:\Chem2009\GK6 Fan Dynamics\plotFanCurve.py", line 31, in
<module>
    p.savefig('memo/figures/normalizedFanCurve.pdf')
  File "C:\Python25\lib\site-packages\matplotlib\pyplot.py", line 345,
in savefig
    return fig.savefig(*args, **kwargs)
  File "C:\Python25\lib\site-packages\matplotlib\figure.py", line 990,
in savefig
    self.canvas.print_figure(*args, **kwargs)
  File "C:\Python25\lib\site-packages\matplotlib\backend_bases.py", line
1419, in print_figure
    **kwargs)
  File "C:\Python25\lib\site-packages\matplotlib\backend_bases.py", line
1313, in print_pdf
    return pdf.print_pdf(*args, **kwargs)
  File
"C:\Python25\lib\site-packages\matplotlib\backends\backend_pdf.py", line
1886, in print_pdf
    self.figure.draw(renderer)
  File "C:\Python25\lib\site-packages\matplotlib\figure.py", line 772,
in draw
    for a in self.axes: a.draw(renderer)
  File "C:\Python25\lib\site-packages\matplotlib\axes.py", line 1601, in
draw
    a.draw(renderer)
  File "C:\Python25\lib\site-packages\matplotlib\axis.py", line 725, in
draw
    self.label.draw(renderer)
  File "C:\Python25\lib\site-packages\matplotlib\text.py", line 502, in
draw
    ismath=ismath)
  File
"C:\Python25\lib\site-packages\matplotlib\backends\backend_pdf.py", line
1573, in draw_text
    return draw_text_woven(chunks)
  File
"C:\Python25\lib\site-packages\matplotlib\backends\backend_pdf.py", line
1543, in draw_text_woven
    glyph_name = font.get_glyph_name(gind)
RuntimeError: Face has no glyph names

I can reproduce this error with several fonts on my system.
(Coincidentally, all the fonts that have a full set of superscript
characters, which I could really use for my plots.) I know that these
fonts can be included in PDFs, because I can do it in other programs. I
also checked the archives and the bug list for clues as to what may be
going on, but came up empty. Any idea what the problem might be? Thanks!

Andrew

João Luís Silva <js...@fc...> writes:

> annotate and usetex='True' can trigger a traceback if the text is 
> invalid. A space or an underscore generate this behavior, I haven't 
> tried others.

Thanks for the report it should be fixed now. You still get a traceback,
but now it should make more sense.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hi,

annotate and usetex='True' can trigger a traceback if the text is 
invalid. A space or an underscore generate this behavior, I haven't 
tried others.

Ubuntu 8.10, mpl svn (rev. 7032).

Once again feel free to ignore this, I just feel compelled to report all 
mpl bugs :)

JLS

Example:

#---------------------------------------------------------------------------
from matplotlib import rc
rc('text', usetex=True)
rc('font', family='serif')

import matplotlib.pyplot as plt
import numpy as np

x = np.arange(-10.0,10.0,0.1)
plt.plot(x,np.sin(x))
ax = plt.gca()
ax.annotate(' ',xy=(-5.8,0.5),xytext=(-8.0,0.5),
             arrowprops=dict(facecolor='black',width=1.5, shrink=0.05))

plt.show()
#---------------------------------------------------------------------------



Traceback:

Traceback (most recent call last):
   File 
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py", 
line 352, in expose_event 

     self._render_figure(self._pixmap, w, h) 

   File 
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py", 
line 75, in _render_figure 

     FigureCanvasAgg.draw(self) 

   File 
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
line 283, in draw 

     self.figure.draw(self.renderer) 

   File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 
773, in draw 

     for a in self.axes: a.draw(renderer) 

   File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 
1672, in draw
     a.draw(renderer) 

   File "/usr/lib/python2.5/site-packages/matplotlib/text.py", line 
1615, in draw
     self.update_positions(renderer) 

   File "/usr/lib/python2.5/site-packages/matplotlib/text.py", line 
1542, in update_positions
     l,b,w,h = self.get_window_extent(renderer).bounds
   File "/usr/lib/python2.5/site-packages/matplotlib/text.py", line 662, 
in get_window_extent
     bbox, info = self._get_layout(self._renderer)
   File "/usr/lib/python2.5/site-packages/matplotlib/text.py", line 253, 
in _get_layout
     clean_line, self._fontproperties, ismath=ismath)
   File 
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
line 152, in get_text_width_height_descent
     renderer=self)
   File "/usr/lib/python2.5/site-packages/matplotlib/texmanager.py", 
line 594, in get_text_width_height_descent
     dvi = dviread.Dvi(dvifile, 72*dpi_fraction)
   File "/usr/lib/python2.5/site-packages/matplotlib/dviread.py", line 
45, in __init__
     self.file = open(filename, 'rb')
IOError: [Errno 2] No such file or directory: 
'/home/jls/.matplotlib/tex.cache/557ff391b6beb8d5df7a86de0547f607.dvi'

Hello,

I just thought I'd mention a little more detail about what I've found  
with respect to writing grey/colorscales to vector graphics formats.  
The bottom line is that to plot a grayscale or colorscale in a vector  
graphics format without resampling, it seems at the moment that  
pcolorfast works best, in SVG format (not PS).

Attached is a script to try out different combinations of methods,  
formats, and canvas sizes. In all cases I am plotting a 10x10 numpy  
array. The file sizes I obtain are:

$ du -sh example*
584K	example1.ps    (imshow and 4x4 canvas)
2.2M	example2.ps    (imshow and 8x8 canvas)
  84K	example3.svg   (imshow and 4x4 canvas)
204K	example4.svg   (imshow and 8x8 canvas)
600K	example5.ps    (pcolorfast and 4x4 canvas)
2.3M	example6.ps    (pcolorfast and 8x8 canvas)
  16K	example7.svg   (pcolorfast and 4x4 canvas)
  20K	example8.svg   (pcolorfast and 8x8 canvas)

As you can see, example7.svg and example8.svg are by far the smallest  
files, and their sizes aren't that different, which is the way things  
should be as changing the canvas size shouldn't be changing much since  
it is a vector graphics format. It's interesting to see that imshow  
and pcolorfast produce different results for SVG (both smaller than  
the PS results)

Interestingly, pcolorfast shows no improvement compared to imshow for  
the PS files, and in addition, the 4x4 images are 4 times smaller than  
the 8x8 images, suggesting that in all cases, the colorscale has been  
rasterized to a finer resolution.

It might be worth seeing how the SVG driver implements this and apply  
the same technique to the PS driver. The fact that the SVG driver can  
do this suggests that the matplotlib API should be able to handle this  
and so all that is needed is to work on the PS driver?

As a temporary solution, it is possible to produce SVG files and  
convert these to PS, but this is not an ideal solution.

Let me know if you have any questions about this,

Thanks,

Thomas


  

It is not always clear what should go in the 0.98.5 maintenance branch. 
  For example, is the _png.cpp patch by Tobias, committed by Andrew, a 
bug fix or a new feature?  I would have said the latter, but I can see 
arguments either way.

More generally, how long do we need to keep updating this maintenance 
branch?

And is there a release schedule in mind?  Any prospect of more 
thoroughly automating official releases and of adding svn snapshot 
releases? And of following numpy's buildbot example?

I don't think I can help with any of this; I am just casting about to 
see if there might be someone on the list who is interested and can 
break loose some time.

Eric

On Sun, Apr 5, 2009 at 16:01, David Moore <da...@sj...> wrote:

> I've had matplotlib running fine on Python 2.6 since shortly after the Python
> 2.6 release.  I run Arch Linux.  Are you perhaps looking for Windows builds?
> Or does your distro not have matplotlib compiled for Python 2.6 yet?

No, I'm looking to package matplotlib for python-2.6 on MacPorts and
wanted to check that there would be no unexpected surprises, but from
the above it sounds like all should be good.

Cheers

Adam

On Sunday 05 April 2009 18:49:46 Adam Mercer wrote:
> Hi
>
> Now that numpy-1.3.0 has been released what is the timescale for a
> python-2.6 compatible release of matplotlib and matplotlib-basemap? Or
> should the current release work OK?
>
> Cheers
>
> Adam
>
I've had matplotlib running fine on Python 2.6 since shortly after the Python 
2.6 release.  I run Arch Linux.  Are you perhaps looking for Windows builds?  
Or does your distro not have matplotlib compiled for Python 2.6 yet?

Dave Moore

Hi

Now that numpy-1.3.0 has been released what is the timescale for a
python-2.6 compatible release of matplotlib and matplotlib-basemap? Or
should the current release work OK?

Cheers

Adam

Eric Firing <ef...@ha...> writes:

> I'm not sure who the SVG expert is, and I presume the attached message
> applies to pdf as well as ps. I'm bringing it to your attention
> because it is suggesting what would seem to be significant
> improvements in some backends by taking better advantage of their
> native image support. I know nothing about this; would either of you
> (or anyone else) like to comment?

Thanks for forwarding this Eric - yes, it applies to pdf.

> From: Thomas Robitaille <tho...@gm...>

> I am using matplotlib to create postscript and SVG files. I am
> currently using imshow to show the contents of an array, but this
> means that when saving vector graphics files, matplotlib resamples the
> image/array onto a finer grid. [...] Postscript and SVG (as languages)
> both allow a bitmap of an arbitrary resolution to be scaled,
> translated, and rotated without resampling.

This is complicated by the wide variety of interpolation methods offered
by imshow:

        Acceptable values are *None*, 'nearest', 'bilinear',
          'bicubic', 'spline16', 'spline36', 'hanning', 'hamming',
          'hermite', 'kaiser', 'quadric', 'catrom', 'gaussian',
          'bessel', 'mitchell', 'sinc', 'lanczos',

where None means to use the matplotlibrc value, and I think the default
is bicubic. The 'nearest' case is what you get by simply scaling the
original bitmap, so in that case all vector backends could probably
support skipping the interpolation step. The other interpolation methods
could be programmed in Postscript, but that doesn't help with other
backends - though perhaps PDF shadings (gradient fills) could be hacked
to do this. I don't know anything about SVG.

I wonder how the API between the backend and the image object should
look like. Currently the AxesImage object does essentially

        im = self.make_image(renderer.get_image_magnification())
        renderer.draw_image(round(l), round(b), im, self.axes.bbox.frozen(),
                            clippath, affine)

and then the backend does things like

        h, w = im.get_size_out()
        [...]
        h,w,s = im.as_rgba_str()
        rgba.shape = (h, w, 4)
        rgb = rgba[:,:,:3]
        a = rgba[:,:,3:]

Instead, I suppose AxesImage needs to first query the renderer if it
supports the interpolation being used, and if so, call a new renderer
method, say draw_interpolated_image(im). Or perhaps it could just call
the new method, and its implementation in RendererBase would fall back
to interpolating the image and calling the old draw_image. Vector
backends could override it to be smarter when possible.

A possibly related thought: the pdf backend could render some kinds of
image files by passing through the encoded image data from the original
file, so when e.g. image_demo3.py does

        lena = Image.open('../data/lena.jpg')
        im = imshow(lena, origin='lower')

the pdf backend could try to read the JPEG file directly, and only
decode it into a bitmap if it happens to be a wrong subtype of JPEG. For
someone who's using big image files, this would decrease both rendering
time and output size, but I don't know if there are any actual users and
if the benefit is large enough to justify the added complexity - but if
we modify the API anyway to support non-resampling imshow, it might be
good to keep that use-case in mind.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

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
>
> Chr...@no...
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

John,

About a week ago, I introduced my own mpl toolkit
(http://dl.getdropbox.com/u/178748/AxesGrid/htdocs/index.html) in the
mpl dev-list. And I wonder if this package can be included in the main
matplotlib source.

As a matter of fact, I was a bit reluctant to do this because the
package is poorly documented at this moment. However, other people
(Matthew Turk and Jeff Oishi) showed their interests in this package
going into the main matplotlib source, and they're willing to help me
to improve the documentation (and other aspects).

I couldn't find any policy (or similar thing) about mpl_toolkits.
Currently, my package is consist of several pure python modules, so
including this in the main source would be straight forward.

Regards,

-JJ

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

Chr...@no...

Jouni, Darren,

I'm not sure who the SVG expert is, and I presume the attached message 
applies to pdf as well as ps.  I'm bringing it to your attention because 
it is suggesting what would seem to be significant improvements in some 
backends by taking better advantage of their native image support.  I 
know nothing about this; would either of you (or anyone else) like to 
comment?

Eric

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
> <Nic...@lo...> 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

On Fri, Apr 3, 2009 at 10:00 AM, Nicolas Rougier
<Nic...@lo...> 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

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
> <Nic...@lo...> 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

On Fri, Apr 3, 2009 at 4:17 AM, Nicolas Rougier
<Nic...@lo...> 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

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
> <Nic...@lo...> 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>

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
<Nic...@lo...> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

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

Hey Reiner -- please make sure you "reply-to-all" so others can
participate in the thread.  I'm am CC-ing the reply to the list.

On Wed, Apr 1, 2009 at 5:19 PM, Reinier Heeres <re...@he...> wrote:

> That is one issue, but if I try to solve that I get some
> strange-looking result. It seems that the patches I am drawing are not
> scaled properly; they are way too large. Do you know of any obvious
> change that might have resulted in this (I guess it might be in the
> "transform" parts)? And is there perhaps a nice web-interface to
> compare different versions of various files?

What version of mpl are you using?  The major transform work was done
between 0.91 and 0.98, which is why we removed the 3D stuff at that
time.  I assume you are already on some version of 0.98, so hopefully
the transforms changes from your branch to svn HEAD will be minimal.
The code diffs can be found at
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/

I also removed the TextWithDash and saw the scaling problems you point to.

JDH