matplotlib-devel Mailing List for matplotlib (Page 2)

On Thu, 11 Jan 2007, Rich Shepard wrote:

On Thu, 11 Jan 2007, John Hunter wrote:

> python simple_plot.py --verbose-debug -dAgg >& runagg.out
> python simple_plot.py --verbose-debug -dPS >& runps.out
> python simple_plot.py --verbose-debug -dGTK >& rungtk.out

   These three ran to completion. The last produced a window displaying the
  output.

   When I ran the script with -dWXAgg, it segfaulted.

   Two output files attached; original message bounced because the size was
too large.

Thanks,

Rich

-- 
Richard B. Shepard, Ph.D.               |    The Environmental Permitting
Applied Ecosystem Services, Inc.        |          Accelerator(TM)
<http://www.appl-ecosys.com>     Voice: 503-667-4517      Fax: 503-667-8863

On Thursday 11 January 2007 02:01, Fernando Perez wrote:
> On 1/10/07, Steve Chaplin <ste...@ya...> wrote:
> > On Mon, 2007-01-08 at 11:24 -0500, Darren Dale wrote:
> > > "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcair
> > >o.py", line 11, in ?
> > >     import matplotlib.backends.backend_cairo as be_cairo
> > > AttributeError: 'module' object has no attribute 'backends'
> >
> > The original matplotlib code is correct, you should be editing IPython
> > and correcting their bug!
>
> Well, I'd be delighted to correct the ipython bug, if only I
> understood exactly what the problem was...  As far as I can see, that
> code in ipython is simply calling
>
>         # Initialize matplotlib to interactive mode always
>         import matplotlib
>         from matplotlib import backends
>
> inside a function (the _matplotlib_config method).  I don't see a bug
> in that, but if you provide some pointers, I'll be happy to fix any
> issues that are on ipython's side of the fence.

I've been looking at this, but haven't made much progress. Try this with 
backend:gtkcairo in matplotlibrc:

$ python

>>> __import__('matplotlib.backends.backend_ps', globals(),\
locals(),['backend_ps'])

output:
<module 'matplotlib.backends.backend_ps' 
from '/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_ps.pyc'>

$ ipython

In [1]: __import__('matplotlib.backends.backend_ps', globals(),\
locals(),['backend_ps'])

output:
---------------------------------------------------------------------------
exceptions.AttributeError                            Traceback (most recent 
call last)

/home/darren/<ipython console>

/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py
     54
     55 # a hack to keep old versions of ipython working with mpl
     56 if 'IPython.Shell' in  sys.modules:
---> 57     new_figure_manager, draw_if_interactive, show = pylab_setup()
     58

/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py in 
pylab_setup()
     24     time.sleep(1)
     25     backend_mod = __import__('matplotlib.backends.'+backend_name,
---> 26                              globals(),locals(),[backend_name])
     27
     28     # Things we pull in from all backends

/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py
      7     import cairo.gtk
      8
----> 9 import matplotlib.backends.backend_cairo as be_cairo
     10 from   matplotlib.backends.backend_gtk import *
     11

AttributeError: 'module' object has no attribute 'backends'



If you change backend:gtkagg in matplotlibrc, then ipython doesnt complain. 
Very strange.

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
    Steve> This is the official definition from the manual:
    Steve> CAIRO_FORMAT_ARGB32 each pixel is a 32-bit quantity, with
    Steve> alpha in the upper 8 bits, then red, then green, then
    Steve> blue. The 32-bit quantities are stored
    Steve> native-endian. Pre-multiplied alpha is used. (That is, 50%
    Steve> transparent red is 0x80800000, not 0x80ff0000.)

    Steve> What I think this means is: cairo ARGB32 is stored not as 4
    Steve> 8-bit quantities, but as one 32-bit int.  On big-endian
    Steve> systems the byte order is ARGB, as you would expect, but on
    Steve> little-endian systems (like a PC) the byte order is BGRA.

    Steve> I imagine the reason is that its easier/faster to
    Steve> read/write one 32-bit int than it is to read/write four
    Steve> bytes.

OK, I see the source of my confusion.  argb determines the order but
it doesn't determine whether the most significant bit is first or
last....

I added a method buffer_bgra32 to the image backend.  I'm not sure
this is the right way to deal with the endianness bit it's easy and
will probably work.  I'll leave it to you guys to fix the cairo
backend to selectively call the right method and test it across
platforms, or propose a better solution if you don't like this one...

JDH

On Thu, 2007-01-11 at 08:50 -0600, John Hunter wrote:
> >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
> 
>     Steve> On Mon, 2007-01-08 at 11:24 -0500, Darren Dale wrote:
>     >> I only had a short time to work with backend_gtkcairo, but a
>     >> couple of things caught my attention. mathtext support seemed
>     >> to need some improvement, it looked like it was rendered as an
>     >> image rather than as text. Also, imshow(rand(100,100)) looked
>     >> very different with gtkcairo and gtkagg, (maybe because the
>     >> rgba ordering is different in agg and cairo? I'm not sure this
>     >> is even the case, I'm taking a stab in the dark.)
> 
>     Steve> cairo mathtext uses a method copied from gdk/gtk and does
>     Steve> render an image. It needs updating to render text.
> 
>     Steve> imshow does look different on cairo and agg, and yes, It
>     Steve> looks like an image format problem. cairo uses ARGB32 with
>     Steve> pre-multiplied alpha, and the ARGB order depends on whether
>     Steve> the machine is little- of big-endian.
> 
> I am confused by what you mean about the ARGB order depending on
> endianess.  ARGB defines the order, and each color is one byte, so
> where is the ambiguity?  Do you mean that depending on endianness,
> cairo will use other orderings than ARGB?
> 
> In _image.cpp we provide a few buffer methods for various pixel
> orderings, eg buffer_argb32.  We may need to provide additional
> orderings for cairo, and call the right one depending on the platform.

This is the official definition from the manual:
CAIRO_FORMAT_ARGB32
each pixel is a 32-bit quantity, with alpha in the upper 8 bits, then
red, then green, then blue. The 32-bit quantities are stored
native-endian. Pre-multiplied alpha is used. (That is, 50% transparent
red is 0x80800000, not 0x80ff0000.)

What I think this means is:
cairo ARGB32 is stored not as 4 8-bit quantities, but as one 32-bit int.
On big-endian systems the byte order is ARGB, as you would expect, but
on little-endian systems (like a PC) the byte order is BGRA.

I imagine the reason is that its easier/faster to read/write one 32-bit
int than it is to read/write four bytes.

Steve

Send instant messages to your online friends http://au.messenger.yahoo.com 

On Jan 11, 2007, at 12:55 AM, Steve Chaplin wrote:

>> I have never run into a problem with relative imports, though I don't
>> object to removing them.  Why are they bad style and what is the  
>> danger?
>
> Its because you can unwittingly end up with module name clashes. There
> can be two different modules in two different directories with the  
> same
> name and you import the wrong module by mistake.

Just wanted to chime in here --
with python 2.5, you can have your cake and eat it too:

    from .localpkg import Symbol1, Symbol2
    from . import localpkg

This disambiguates the "calendar.py" problem that you had (and that  
about 90% of python coders have had at least once in their lives). :)


-Peter

On Thursday 11 January 2007 09:42, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
>     Darren> I had to alter the following lines from backend_gtkcairo,
>     Darren> from
>
>     Darren> import matplotlib.backends.backend_cairo as be_cairo from
>     Darren> matplotlib.backends.backend_gtk import *
>
>     Darren>
> "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py
>", Darren> line 11, in ?  import matplotlib.backends.backend_cairo as
> Darren> be_cairo AttributeError: 'module' object has no attribute Darren>
> 'backends'
>
>
> My guess is that you were running your test code in which there was a
> "matplotlib" dir that was not *the* matplotlib install dir.
>
> Possible?

It wouldn't have been the first time I made that mistake, but that doesn't 
seem to be the problem.

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> On Mon, 2007-01-08 at 11:24 -0500, Darren Dale wrote:
    >> I only had a short time to work with backend_gtkcairo, but a
    >> couple of things caught my attention. mathtext support seemed
    >> to need some improvement, it looked like it was rendered as an
    >> image rather than as text. Also, imshow(rand(100,100)) looked
    >> very different with gtkcairo and gtkagg, (maybe because the
    >> rgba ordering is different in agg and cairo? I'm not sure this
    >> is even the case, I'm taking a stab in the dark.)

    Steve> cairo mathtext uses a method copied from gdk/gtk and does
    Steve> render an image. It needs updating to render text.

    Steve> imshow does look different on cairo and agg, and yes, It
    Steve> looks like an image format problem. cairo uses ARGB32 with
    Steve> pre-multiplied alpha, and the ARGB order depends on whether
    Steve> the machine is little- of big-endian.

I am confused by what you mean about the ARGB order depending on
endianess.  ARGB defines the order, and each color is one byte, so
where is the ambiguity?  Do you mean that depending on endianness,
cairo will use other orderings than ARGB?

In _image.cpp we provide a few buffer methods for various pixel
orderings, eg buffer_argb32.  We may need to provide additional
orderings for cairo, and call the right one depending on the platform.

JDH

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> I had to alter the following lines from backend_gtkcairo,
    Darren> from

    Darren> import matplotlib.backends.backend_cairo as be_cairo from
    Darren> matplotlib.backends.backend_gtk import *

    Darren> "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py",
    Darren> line 11, in ?  import matplotlib.backends.backend_cairo as
    Darren> be_cairo AttributeError: 'module' object has no attribute
    Darren> 'backends'


My guess is that you were running your test code in which there was a
"matplotlib" dir that was not *the* matplotlib install dir.

Possible?

JDH

On Mon, 2007-01-08 at 11:24 -0500, Darren Dale wrote: 
> I only had a short time to work with backend_gtkcairo, but a couple of things 
> caught my attention. mathtext support seemed to need some improvement, it 
> looked like it was rendered as an image rather than as text. Also, 
> imshow(rand(100,100)) looked very different with gtkcairo and gtkagg, (maybe 
> because the rgba ordering is different in agg and cairo? I'm not sure this is 
> even the case, I'm taking a stab in the dark.)

cairo mathtext uses a method copied from gdk/gtk and does render an
image. It needs updating to render text.

imshow does look different on cairo and agg, and yes, It looks like an
image format problem. cairo uses ARGB32 with pre-multiplied alpha, and
the ARGB order depends on whether the machine is little- of big-endian.

Steve

Send instant messages to your online friends http://au.messenger.yahoo.com 

On 1/10/07, Steve Chaplin <ste...@ya...> wrote:
> On Mon, 2007-01-08 at 11:24 -0500, Darren Dale wrote:

> > I had to alter the following lines from backend_gtkcairo, from
> >
> > import matplotlib.backends.backend_cairo as be_cairo
> > from   matplotlib.backends.backend_gtk import *
> >
> > to
> >
> > import backend_cairo as be_cairo
> > from   backend_gtk import *
> >
> > in order to prevent the following traceback:
> >
> > Traceback (most recent call last):
> >   File "/usr/bin/ipython", line 27, in ?
> >     IPython.Shell.start().mainloop()
> >   File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 1034, in
> > start
> >     return shell(user_ns = user_ns)
> >   File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 945, in
> > __init__
> >     shell_class=MatplotlibMTShell)
> >   File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 622, in
> > __init__
> >     on_kill=[mainquit])
> >   File "/usr/lib64/python2.4/site-packages/IPython/ipmaker.py", line 90, in
> > make_IPython
> >     embedded=embedded,**kw)
> >   File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 506, in
> > __init__
> >     user_ns,b2 = self._matplotlib_config(name,user_ns)
> >   File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 397, in
> > _matplotlib_config
> >     from matplotlib import backends
> >   File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py",
> > line 55, in ?
> >     new_figure_manager, draw_if_interactive, show = pylab_setup()
> >   File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py",
> > line 23, in pylab_setup
> >     globals(),locals(),[backend_name])
> >
> > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py",
> > line 11, in ?
> >     import matplotlib.backends.backend_cairo as be_cairo
> > AttributeError: 'module' object has no attribute 'backends'
>
> The original matplotlib code is correct, you should be editing IPython
> and correcting their bug!

Well, I'd be delighted to correct the ipython bug, if only I
understood exactly what the problem was...  As far as I can see, that
code in ipython is simply calling

        # Initialize matplotlib to interactive mode always
        import matplotlib
        from matplotlib import backends

inside a function (the _matplotlib_config method).  I don't see a bug
in that, but if you provide some pointers, I'll be happy to fix any
issues that are on ipython's side of the fence.

Cheers,

f

On Wed, 2007-01-10 at 11:55 -0600, John Hunter wrote:
> >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
> 
>     Steve> Matplotlib does use a lot of relative imports which I think
>     Steve> is bad style.
> 
>     Steve> See PEP 8 "Style Guide for Python Code"
>     Steve> http://www.python.org/dev/peps/pep-0008/
> 
>     Steve>     - Relative imports for intra-package imports are highly
>     Steve> discouraged.  Always use the absolute package path for all
>     Steve> imports.  Even now that PEP 328 [7] is fully implemented in
>     Steve> Python 2.5, its style of explicit relative imports is
>     Steve> actively discouraged; absolute imports are more portable
>     Steve> and usually more readable.
> 
> I have never run into a problem with relative imports, though I don't
> object to removing them.  Why are they bad style and what is the danger?

Its because you can unwittingly end up with module name clashes. There
can be two different modules in two different directories with the same
name and you import the wrong module by mistake. It happened to me once
when I created a 'calendar.py' module and didn't realize that Python
already has a calendar module. Its hard to debug because you get a
traceback which makes no sense.

>From PEP328
http://www.python.org/dev/peps/pep-0328/

Rationale for Absolute Imports
In Python 2.4 and earlier, if you're reading a module located inside a
package, it is not clear whether

import foo

refers to a top-level module or to another module inside the package. As
Python's library expands, more and more existing package internal
modules suddenly shadow standard library modules by accident. It's a
particularly difficult problem inside packages because there's no way to
specify which module is meant. To resolve the ambiguity, it is proposed
that foo will always be a module or package reachable from sys.path.
This is called an absolute import.

Steve

Send instant messages to your online friends http://au.messenger.yahoo.com 

> I have never run into a problem with relative imports, though I don't
> object to removing them.  Why are they bad style and what is the danger?

I had assumed because it would not be as obvious that the imports were
local modules, but might be wrong...

Best,

Matthew

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> Matplotlib does use a lot of relative imports which I think
    Steve> is bad style.

    Steve> See PEP 8 "Style Guide for Python Code"
    Steve> http://www.python.org/dev/peps/pep-0008/

    Steve>     - Relative imports for intra-package imports are highly
    Steve> discouraged.  Always use the absolute package path for all
    Steve> imports.  Even now that PEP 328 [7] is fully implemented in
    Steve> Python 2.5, its style of explicit relative imports is
    Steve> actively discouraged; absolute imports are more portable
    Steve> and usually more readable.

I have never run into a problem with relative imports, though I don't
object to removing them.  Why are they bad style and what is the danger?

    Steve> There was a recent "Coding Guide" thread on this list
    Steve> (which I admit I just skimmed through). Instead of
    Steve> reinventing the wheel, how about stating at the top of
    Steve> CODING_GUIDE that PEP 8 is the default style for
    Steve> matplotlib, and the following notes give in-depth
    Steve> matplotlib examples (or possibly override PEP 8 if
    Steve> necessary).

Agreed -- I'll update the coding style section to refer to this
document, and provide a few comments in line.

JDH

On Mon, 2007-01-08 at 11:24 -0500, Darren Dale wrote: 
> > > What would need to be done in mpl, and how hard would it be?
> >
> > The cairo backend can already be used for png, ps, pdf and gtk output so
> > I don't think there would be much to do. Mostly, it needs testing -
> > running all the mpl examples and checking the output looks OK.
> 
> I had to alter the following lines from backend_gtkcairo, from 
> 
> import matplotlib.backends.backend_cairo as be_cairo
> from   matplotlib.backends.backend_gtk import *
> 
> to
> 
> import backend_cairo as be_cairo
> from   backend_gtk import *
> 
> in order to prevent the following traceback:
> 
> Traceback (most recent call last):
>   File "/usr/bin/ipython", line 27, in ?
>     IPython.Shell.start().mainloop()
>   File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 1034, in 
> start
>     return shell(user_ns = user_ns)
>   File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 945, in 
> __init__
>     shell_class=MatplotlibMTShell)
>   File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 622, in 
> __init__
>     on_kill=[mainquit])
>   File "/usr/lib64/python2.4/site-packages/IPython/ipmaker.py", line 90, in 
> make_IPython
>     embedded=embedded,**kw)
>   File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 506, in 
> __init__
>     user_ns,b2 = self._matplotlib_config(name,user_ns)
>   File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 397, in 
> _matplotlib_config
>     from matplotlib import backends
>   File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py", 
> line 55, in ?
>     new_figure_manager, draw_if_interactive, show = pylab_setup()
>   File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py", 
> line 23, in pylab_setup
>     globals(),locals(),[backend_name])
>   
> File "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py", 
> line 11, in ?
>     import matplotlib.backends.backend_cairo as be_cairo
> AttributeError: 'module' object has no attribute 'backends'

The original matplotlib code is correct, you should be editing IPython
and correcting their bug!
Matplotlib does use a lot of relative imports which I think is bad
style.

See PEP 8 "Style Guide for Python Code"
http://www.python.org/dev/peps/pep-0008/

    - Relative imports for intra-package imports are highly discouraged.
      Always use the absolute package path for all imports.
      Even now that PEP 328 [7] is fully implemented in Python 2.5,
      its style of explicit relative imports is actively discouraged;
      absolute imports are more portable and usually more readable.

There was a recent "Coding Guide" thread on this list (which I admit I just
skimmed through). Instead of reinventing the wheel, how about stating at the
top of CODING_GUIDE that PEP 8 is the default style for matplotlib, and the
following notes give in-depth matplotlib examples (or possibly override
PEP 8 if necessary).

Steve

Send instant messages to your online friends http://au.messenger.yahoo.com 

Steve Chaplin wrote:
> On Mon, 2007-01-08 at 10:09 -0600, John Hunter wrote: 
>>>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
>>     Steve> My general impression of the cairo "surfaces" is:
>>     Steve> ImageSurface/png - support is very good gtk/xlib - support
>>     Steve> is very good ps/pdf/svg are usable but less mature and
>>     Steve> still developing so there may be occasional problems
>>     Steve> drawing specific items ps - it used to embed bitmap images
>>     Steve> but now most output is vector based eps - is not supported
>>     Steve> yet, but may be in a future version
>>
>> This was my impression too - that it used to be raster PS but now uses
>> vector, but the web page seems to be claiming otherwise.
> Which specific web page says otherwise?

http://cairographics.org/backends

It looks like this simply has not been kept up to date.

Eric

On Mon, 2007-01-08 at 10:09 -0600, John Hunter wrote: 
> >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
>     Steve> My general impression of the cairo "surfaces" is:
>     Steve> ImageSurface/png - support is very good gtk/xlib - support
>     Steve> is very good ps/pdf/svg are usable but less mature and
>     Steve> still developing so there may be occasional problems
>     Steve> drawing specific items ps - it used to embed bitmap images
>     Steve> but now most output is vector based eps - is not supported
>     Steve> yet, but may be in a future version
> 
> This was my impression too - that it used to be raster PS but now uses
> vector, but the web page seems to be claiming otherwise.
Which specific web page says otherwise?

Steve


Send instant messages to your online friends http://au.messenger.yahoo.com 

On Monday 08 January 2007 12:02, John Hunter wrote:
> >>>>> "John" == John Hunter <jdh...@ac...> writes:
> >>>>>
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
>     Darren> This would really be a plus. The option to use latex for
>     Darren> text layout would have to be completely reworked, if it
>     Darren> could be supported at all. Not that this is a critical
>     Darren> feature, but in my opinion it is still necessary at this
>     Darren> point for producing the highest quality plots for
>     Darren> publication.
>
>     John> For many people this is absolutely the killer feature of mpl
>
> But I should add if cairo the cairo ps backend had good image support,
> we could put 6000 dpi images into the ps backend for the latex
> mathtext which would be fine.

On the other hand, you would then lose the ability to search a pdf file for 
text in the figures. This is currently only possible using by setting 
ps.usedistiller to "xpdf", but it is a really nice feature.

On Monday 08 January 2007 11:51, Nicholas Young wrote:
> Darren Dale wrote:
> > Hi Steve, Eric, John,
> >
> > On Sunday 07 January 2007 04:44, Steve Chaplin wrote:
> >> On Sat, 2007-01-06 at 09:23 -1000, Eric Firing wrote:
> >>> How do you see the future of a cairo backend as a prospective
> >>> replacement for most or all of the primary mpl backends?
> >>
> >> I think cairo could potentially be used to replace the pdf, ps, svg
> >> and gdk/gtk backends which would unify most of the backends and simplify
> >> a lot of the code.
> >
> > This would really be a plus. The option to use latex for text layout
> > would have to be completely reworked, if it could be supported at all.
> > Not that this is a critical feature, but in my opinion it is still
> > necessary at this point for producing the highest quality plots for
> > publication.
>
> Playing around with using Cairo for something else, I once wrote some
> code to convert dvi to Cairo.  The code I wrote probably isn't suitable
> for use by matplotlib, but it wasn't particularly difficult to
> write.  The most difficult thing was finding the correct fonts - but I
> know people on this list have a lot of experience with that kind of
> problem anyway.  It is possible the code would need to be in c/c++ for
> speed - my code was anyway so I don't know.
>
> I would offer to write something myself, but I'm leaving the field in
> which I use matplotlib around now and I wouldn't be able to maintain
> anything I wrote.

Would you be willing to contribute this code to mpl? If so, please forward it 
to me off list. I would really like to have a look.

Darren

>>>>> "John" == John Hunter <jdh...@ac...> writes:

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
    Darren> This would really be a plus. The option to use latex for
    Darren> text layout would have to be completely reworked, if it
    Darren> could be supported at all. Not that this is a critical
    Darren> feature, but in my opinion it is still necessary at this
    Darren> point for producing the highest quality plots for
    Darren> publication.

    John> For many people this is absolutely the killer feature of mpl

But I should add if cairo the cairo ps backend had good image support,
we could put 6000 dpi images into the ps backend for the latex
mathtext which would be fine.

JDH

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
    Darren> This would really be a plus. The option to use latex for
    Darren> text layout would have to be completely reworked, if it
    Darren> could be supported at all. Not that this is a critical
    Darren> feature, but in my opinion it is still necessary at this
    Darren> point for producing the highest quality plots for
    Darren> publication.

For many people this is absolutely the killer feature of mpl

JDH

Darren Dale wrote:
> Hi Steve, Eric, John,
> On Sunday 07 January 2007 04:44, Steve Chaplin wrote:
>> On Sat, 2007-01-06 at 09:23 -1000, Eric Firing wrote:
>>> How do you see the future of a cairo backend as a prospective
>>> replacement for most or all of the primary mpl backends?
>> I think cairo could potentially be used to replace the pdf, ps, svg
>> and gdk/gtk backends which would unify most of the backends and simplify
>> a lot of the code.
> 
> This would really be a plus. The option to use latex for text layout would 
> have to be completely reworked, if it could be supported at all. Not that 
> this is a critical feature, but in my opinion it is still necessary at this 
> point for producing the highest quality plots for publication.

Playing around with using Cairo for something else, I once wrote some
code to convert dvi to Cairo.  The code I wrote probably isn't suitable
for use by matplotlib, but it wasn't particularly difficult to
write.  The most difficult thing was finding the correct fonts - but I 
know people on this list have a lot of experience with that kind of 
problem anyway.  It is possible the code would need to be in c/c++ for 
speed - my code was anyway so I don't know.

I would offer to write something myself, but I'm leaving the field in
which I use matplotlib around now and I wouldn't be able to maintain
anything I wrote.

Nicholas

Hi Steve, Eric, John,

On Sunday 07 January 2007 04:44, Steve Chaplin wrote:
> On Sat, 2007-01-06 at 09:23 -1000, Eric Firing wrote:
> > Steve,
> >
> > Darren Dale raised a question offline that I think will be of general
> > interest to mpl devels, and that you are the person to answer:
> >
> > How do you see the future of a cairo backend as a prospective
> > replacement for most or all of the primary mpl backends?
>
> I think cairo could potentially be used to replace the pdf, ps, svg
> and gdk/gtk backends which would unify most of the backends and simplify
> a lot of the code.

This would really be a plus. The option to use latex for text layout would 
have to be completely reworked, if it could be supported at all. Not that 
this is a critical feature, but in my opinion it is still necessary at this 
point for producing the highest quality plots for publication.

> > What would need to be completed in cairo? Based on the cairo web page, I
> > get the impression that quite a bit is still missing, including eps
> > generation and genuine vector ps.  But maybe the web page is just out of
> > date.
>
> Which web page is out of date? Where does it mention eps and ps, I
> couldn't find it.
>
> My general impression of the cairo "surfaces" is:
> ImageSurface/png - support is very good
> gtk/xlib - support is very good
> ps/pdf/svg are usable but less mature and still developing so there may
>             be occasional problems drawing specific items
> ps - it used to embed bitmap images but now most output is vector based
> eps - is not supported yet, but may be in a future version
>
> > What would need to be done in mpl, and how hard would it be?
>
> The cairo backend can already be used for png, ps, pdf and gtk output so
> I don't think there would be much to do. Mostly, it needs testing -
> running all the mpl examples and checking the output looks OK.

I had to alter the following lines from backend_gtkcairo, from 

import matplotlib.backends.backend_cairo as be_cairo
from   matplotlib.backends.backend_gtk import *

to

import backend_cairo as be_cairo
from   backend_gtk import *

in order to prevent the following traceback:

Traceback (most recent call last):
  File "/usr/bin/ipython", line 27, in ?
    IPython.Shell.start().mainloop()
  File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 1034, in 
start
    return shell(user_ns = user_ns)
  File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 945, in 
__init__
    shell_class=MatplotlibMTShell)
  File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 622, in 
__init__
    on_kill=[mainquit])
  File "/usr/lib64/python2.4/site-packages/IPython/ipmaker.py", line 90, in 
make_IPython
    embedded=embedded,**kw)
  File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 506, in 
__init__
    user_ns,b2 = self._matplotlib_config(name,user_ns)
  File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 397, in 
_matplotlib_config
    from matplotlib import backends
  File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py", 
line 55, in ?
    new_figure_manager, draw_if_interactive, show = pylab_setup()
  File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py", 
line 23, in pylab_setup
    globals(),locals(),[backend_name])
  
File "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py", 
line 11, in ?
    import matplotlib.backends.backend_cairo as be_cairo
AttributeError: 'module' object has no attribute 'backends'


I only had a short time to work with backend_gtkcairo, but a couple of things 
caught my attention. mathtext support seemed to need some improvement, it 
looked like it was rendered as an image rather than as text. Also, 
imshow(rand(100,100)) looked very different with gtkcairo and gtkagg, (maybe 
because the rgba ordering is different in agg and cairo? I'm not sure this is 
even the case, I'm taking a stab in the dark.)


> > Would mpl get slower if everything went through cairo?
>
> Not sure, you would need to run cairo and test it. It used to be much
> slower than Agg but more recent versions have had many optimisations
> applied and the difference is much smaller now.
>
> > Any other considerations?
>
> Some parts of mpl are Agg-specific and other parts (the whole drawing
> model) are designed around the gdk drawing style - this makes things harder
> and inefficient when using cairo.

I'm just thinking out loud here, brainstorming, but may be getting completely 
ahead of myself. Feel free to tell me so. If we made a mpl-pre1.0 branch, and 
reconstructed the drawing model, how much work are we talking about? Since 
gtk includes cairo now, couldn't a single gtk backend replace both gtk and 
gtkagg, while retaining the speed of the pure gtk backend?

> On Sat, 2007-01-06 at 09:36 -1000, Eric Firing wrote:
> > One more question: how does the image quality of cairo compare to
> > Agg?
> > Is the antialiasing as good?
>
> Image quality looks OK to me, but I'm no expert.
>
> The web browser Firefox 3.0 (due to be released early in 2007) will use
> cairo for all rendering. Firefox requires a high level of graphics
> performance and the upcoming cairo 1.4 release is expected to provide
> that.

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
    Steve> My general impression of the cairo "surfaces" is:
    Steve> ImageSurface/png - support is very good gtk/xlib - support
    Steve> is very good ps/pdf/svg are usable but less mature and
    Steve> still developing so there may be occasional problems
    Steve> drawing specific items ps - it used to embed bitmap images
    Steve> but now most output is vector based eps - is not supported
    Steve> yet, but may be in a future version

This was my impression too - that it used to be raster PS but now uses
vector, but the web page seems to be claiming otherwise.  In any case,
the LGPL/MPL (mozilla public license not to be confused with
matplotlib) seems to preclude our using it as our "core" renderer.
Unfortunately, Agg itself recently switched over to a GPL license, but
at least we have the 2.4 code base under BSD.  We'll be in the same
position as enthought and a few other companies who are relying on the
BSD agg branch.  At this state I think it advisable to make sure the
cairo backend stays up to snuff in case the agg situation eventually
becomes untenable, but agg is fairly stable and doesn't import
anything, event the C++ standard library, so 2.4 should be good for
some time to come.  Hopefully the community (including us) will
maintain it.

Sigh,
JDH

On Sat, 2007-01-06 at 09:23 -1000, Eric Firing wrote:
> Steve,
> 
> Darren Dale raised a question offline that I think will be of general 
> interest to mpl devels, and that you are the person to answer:
> 
> How do you see the future of a cairo backend as a prospective 
> replacement for most or all of the primary mpl backends?
I think cairo could potentially be used to replace the pdf, ps, svg
and gdk/gtk backends which would unify most of the backends and simplify
a lot of the code.

> What would need to be completed in cairo? Based on the cairo web page, I 
> get the impression that quite a bit is still missing, including eps 
> generation and genuine vector ps.  But maybe the web page is just out of 
> date.
Which web page is out of date? Where does it mention eps and ps, I
couldn't find it.

My general impression of the cairo "surfaces" is:
ImageSurface/png - support is very good
gtk/xlib - support is very good
ps/pdf/svg are usable but less mature and still developing so there may
            be occasional problems drawing specific items
ps - it used to embed bitmap images but now most output is vector based
eps - is not supported yet, but may be in a future version

> What would need to be done in mpl, and how hard would it be?
The cairo backend can already be used for png, ps, pdf and gtk output so
I don't think there would be much to do. Mostly, it needs testing -
running all the mpl examples and checking the output looks OK.

> Would mpl get slower if everything went through cairo?
Not sure, you would need to run cairo and test it. It used to be much slower
than Agg but more recent versions have had many optimisations applied and
the difference is much smaller now.

> Any other considerations?
Some parts of mpl are Agg-specific and other parts (the whole drawing model)
are designed around the gdk drawing style - this makes things harder and
inefficient when using cairo.

On Sat, 2007-01-06 at 09:36 -1000, Eric Firing wrote:
> One more question: how does the image quality of cairo compare to
> Agg? 
> Is the antialiasing as good? 
Image quality looks OK to me, but I'm no expert.

The web browser Firefox 3.0 (due to be released early in 2007) will use
cairo for all rendering. Firefox requires a high level of graphics
performance and the upcoming cairo 1.4 release is expected to provide
that.

Steve

Send instant messages to your online friends http://au.messenger.yahoo.com 

Steve,

One more question: how does the image quality of cairo compare to Agg? 
Is the antialiasing as good?

Thanks.

Eric