matplotlib-users Mailing List for matplotlib (Page 2)

>>>>> "Edward" == Edward Abraham <Edw...@da...> writes:

    Edward> Interactive use is great, but I need to draw Matlplotlib
    Edward> plots to a window from within a wx application. The
    Edward> example linked to from the screenshots page
    Edward> (embedding_in_wx.py) is broken. I have attached a simple
    Edward> modified version (no toolbar, just a plot). Matplotlib
    Edward> window redraws are quite slow, and the default behaviour
    Edward> is ugly during resizing. The example shows how to modify
    Edward> the FigureCanvas class to redraw only during idle
    Edward> time. This means that there is only one redraw during
    Edward> resizing. The wxagg backend is chosen, as for the simple
    Edward> plot shown here it is quicker than the current
    Edward> implementation of the wx backend.

OK, thanks for letting me know.  I updated the website - the link
should have, and now does, point to examples/embedding_wx2.py.  Note
the matplotlib examples dir, with the src distribution and at
http://matplotlib.sf.net/examples, does contain a few examples showing
how to embed matplotlib into WX/WXAgg.  Eg, examples/embedding_wx2.py
shows how embed use the toolbar as well.

Would you mind if I add your example to the examples subdir?

Thanks!
JDH

Hi, in some analysis, I really think it useful if you can 
add a crosshair feature so I can visually align the position 
of peaks and falls (like the stock market), and may be not 
hard to include, too. Basically, if the "crosshair" checkbox 
checked, a horizontal and a vertical line will appear with 
the movement of the mouse. 

Bao  

Thanks.  Exactly what I was looking for.

Merry Xmas!

CS


On Thu, Dec 23, 2004 at 11:00:41PM -0800, Andrew Straw wrote:
> seb...@sp... wrote:
>
> >Attached is a pcolor plot made with Matplotlib.
> >
> >I was wondering if there is any way I can remove
> >thin black lines (borders) in this plot for cases
> >like this where I don't have zillions of rectangles
> >to make black lines too small to notice.
> >
> >
> >
> Does the docstring for pcolor help?
>
>      * shading = 'flat' : or 'faceted'.  If 'faceted', a black grid is
>        drawn around each rectangle; if 'flat', edge colors are same as
>        face colors
>
> Try
>
> pcolor( your_other_args, shading='flat')
>
> Cheers!
> Andrew
>

--
_______________________________________

Christian Seberino, Ph.D.
SPAWAR Systems Center San Diego
Code 2872
49258 Mills Street, Room 158
San Diego, CA 92152-5385
U.S.A.

Phone: (619) 553-9973
Fax  : (619) 553-6521
Email: seb...@sp...
_______________________________________

Stephen Walton wrote:

>On Wed, 2004-12-22 at 17:30 -0600, John Hunter wrote:
>
>  
>
>> - 4x image speedups for large images
>>    
>>
>
>This is a biggie!!  Ladies and gentlemen, my impression is that imshow
>is now at least as fast as, and perhaps faster than, DS9 for
>astronomical image display.  (I'm looking at 1024 square full disk solar
>images.)  Nice job, John.
>  
>
I therefore propose that we start developing a Python version of DS9. 
The benefits of a Python version based on matplotlib are TrueType fonts 
(with arbitrary text rotation), alpha blending, and direct support for 
numarray.

 -- Paul

-- 
Paul Barrett, PhD      Space Telescope Science Institute
Phone: 410-338-4475    ESS/Science Software Branch
FAX:   410-338-4767    Baltimore, MD 21218

seb...@sp... wrote:

>Attached is a pcolor plot made with Matplotlib.
>
>I was wondering if there is any way I can remove
>thin black lines (borders) in this plot for cases
>like this where I don't have zillions of rectangles
>to make black lines too small to notice.
>
>  
>
Does the docstring for pcolor help?

      * shading = 'flat' : or 'faceted'.  If 'faceted', a black grid is
        drawn around each rectangle; if 'flat', edge colors are same as
        face colors

Try

pcolor( your_other_args, shading='flat')

Cheers!
Andrew

Attached is a pcolor plot made with Matplotlib.

I have lots of rectangles of different colors which
Matplotlib created wonderfully which was exactly
what I was trying to do.

(I have 400 rectangles across the plot in horizontal
direction.)

It appears there are small black borders (padding?) to all little
colored rectangles that make the plot appear more
choppy and less 'blended' in color than I would prefer.
It may be that I *must* have more rectangles to make
these black borders be invisible.

I was wondering if there is any way I can remove
thin black lines (borders) in this plot for cases
like this where I don't have zillions of rectangles
to make black lines too small to notice.

Chris


--
_______________________________________

Christian Seberino, Ph.D.
SPAWAR Systems Center San Diego
Code 2872
49258 Mills Street, Room 158
San Diego, CA 92152-5385
U.S.A.

Phone: (619) 553-9973
Fax  : (619) 553-6521
Email: seb...@sp...
_______________________________________

Hi All,

I am fairly new to matplotlib, and I am impressed with its
capabilities.

I have trouble plotting loglog plots with errorbars. I have
the following, program, a slightly modified version of one
given earlier by JDH on 9-28-2004 in this mailing list:
------------------------------------------------------
from matplotlib.matlab import *
import random

random.seed(13)
## with 10 elements it works
## but with 11 elements it crashes
x = arange(1.0,12)
y = array(map(lambda s:1e6*random.random()+1e5+1,x))
err = array(map(lambda s:1e5*random.random(),x))

print x,y,err
print y-err
ax = gca()
errorbar(x,y,err,fmt='o')
##plot(x,y)
ax.set_yscale("log")
ax.set_xscale("log")
show()
-------------------------------------------------------
The weird thing is that it runs with 10 points, but not
with 11 or more. I guess the random generator happens to generate
a configuration which breaks the routine. I did check
that everything is positive (BTW, it would be great to have
a version which simply ignores negative/0 values), the last
point does not seem special, I can't figure out what's going on.

I run matplotlib 0.64 (sorry I did not convert to pylab yet),
on python 2.3.4/gcc 3.3.1 under a fairly new cygwin installation in
WinXP SP2.

any clue anybody?

thanks, I.
ps. Merry Xmas/Happy Holidays to everybody!
-----------------------------------------------------------
Istvan Szapudi
Institute for Astronomy
University of Hawaii
2680 Woodlawn Drive
Honolulu, HI 96822
USA
Tel. :  (808) 956-6196 (also x9844 in Febr/March)
Fax  :  (808) 956-9590
Email: sz...@if...
WWW  : http://www.ifa.hawaii.edu/~szapudi/istvan.html
-----------------------------------------------------------

On Wed, 2004-12-22 at 17:30 -0600, John Hunter wrote:

>  - 4x image speedups for large images

This is a biggie!!  Ladies and gentlemen, my impression is that imshow
is now at least as fast as, and perhaps faster than, DS9 for
astronomical image display.  (I'm looking at 1024 square full disk solar
images.)  Nice job, John.

Happy happy to all,
Steve

John,

Many thanks for the lengthy and thorough explanations on transformations 
in matplotlib. I am working my way through them and the source files. I 
am still trying to get my line+triangle example to work; i think it 
might be flexible in the end, if we want to, e.g., position the head 
anywhere along the stem, or use different polygons for the head. Your 
polygon example is certainly flexible for shaping the arrow, but for 
instance, if i want to draw an 'oriented path' in 2d space, it will 
become more complicated.

I can now position the stem correctly and the head 'almost' correctly 
using offsets. Here is what i have in my Arrow class:

  orig, dest = zip( xdata, ydata )
  self._x = tuple( xdata )
  self._y = tuple( ydata )
  self._center = dest    # Temporary
  radius = 4

  # Stem
  self._stem = Line2D( self._x, self._y, **kwargs )
  self._stem.set_transform( ax.transData )

  # Head
  self._head = RegularPolygon( tuple(self._center), 3, 

      radius = radius, orientation = angle, **kwargs )
  trans = identity_affine()
  trans.set_offset( tuple( dest ), ax.transData )
  self._head.set_transform( trans )

and the draw() method just says:

  def draw( self, renderer ):
         # Draw stem and head
         self._stem.draw( renderer )
         self._head.draw( renderer )

You instantiate it, for example, with:

  ax = axes( [0.1, 0.1, 0.8, 0.8], polar = polar )
  ax.set_xlim( [0,10] )
  ax.set_ylim( [0,10] )
  arr = ax.arrow( [1, 4], [1, 5] )

to draw an arrow from (1,1) to (4,5).

There are two things:
1) I know the center of the arrow head isn't right; i'll shift it later
2) The arrow is drawn correctly (even on polar axes) but there is a 
slight gap between the tip of the stem and the bottom of the head; 
although the center should coincide with the tip (called 'dest' in the 
code excerpt).

Why isn't the triangle centered where the tip of the stem is?

Dominique

>
>
>    John> Thanks very much indeed -- that has me sorted.  I'll give
>    John> imshow a go as well when I get a chance.
>
>    John> I've attached an image of the results to give you an idea
>    John> what I'm up to.
>
>Very nice..  what do the colors represent, pray tell? 
>
Nothing too exciting I'm afraid. I've got this object I call an atlas 
which is a collection of maps. Each map specifies the list of shapes 
(=countries/states/counties etc) that make up the particular map.

Anyway, to produce this picture I just numbered each country according 
to the order it appears in the list in my 'World' map. This is just a 
toy I've been using for testing.

> Also, in case
>you missed the announcement for 0.65, matplotlib now a number of new
>colormaps, in addition to the trusty jet.
>
>   autumn bone cool copper flag gray hot hsv jet pink prism spring
>   summer winter
>
I did see that -- I'll have to see about making the colour map choice 
available to everyone (or maybe just check today's date and use spring, 
summer, autumn, winter as appropriate).

John

>>>>> "John" == John Gill <jn...@eu...> writes:

    John> Thanks very much indeed -- that has me sorted.  I'll give
    John> imshow a go as well when I get a chance.

    John> I've attached an image of the results to give you an idea
    John> what I'm up to.

Very nice..  what do the colors represent, pray tell?  Also, in case
you missed the announcement for 0.65, matplotlib now a number of new
colormaps, in addition to the trusty jet.

   autumn bone cool copper flag gray hot hsv jet pink prism spring
   summer winter

    John> I can't praise matplotlib highly enough, it has done 90% of
    John> the hard work in getting a very handy mapping tool together
    John> in a matter of days.

Great - thanks for the encouragement.

    John> Hope Santa brings you what you deserve.

With three kids, why do I get the feeling I won't be on the receiving
end of Christmas this year? :-)

JDH

>>>>> "John" == John Gill <jn...@eu...> writes:

    John> I'm having trouble getting the alpha keyword to do anything
    John> when I use the OO interface (as per gtk embeded example).

I'm not sure about the exact status of alpha vis-a-vis alpha - perhaps
Steve can clarify.  a gdk.Color does not have and alpha channel, nor
does a gdk.GC, but a gdk.Pixbuf does.  Basically, alpha is (mostly)
unsupported on the GTK backend (you can do alpha blending of images
because antigrain handles images across backends).  

But you should probably be using the gtkagg backend, which has alpha
support for all plot elements, and does a better job of anti-aliasing.
In some measurements, eg animation, it is a little slower than the
pure GTK backend, so you may want to do a little profiling.  It will
probably be faster than GTK for large collections, perhaps 2x or so,
since it does the collection drawing in extension code and the other
backends have a python implementation.

    John> Aside from this, I'd just like to say what a great package
    John> matplotlib is.  I've been using it a lot the last week to
    John> plot maps -- first I started using pcolor to plot hurricane
    John> footprints (I'll see if I can get the OK to release some of
    John> the plots, pcolor produced some wonderful pictures with a
    John> few lines of code).

if/when you have regularly spaced grids, imshow will likely be an
order of magnitude faster than pcolor for large data sets, so keep it
in mind....

    John> Inspired by this I've also been plotting simple maps by
    John> creating collections of polygons (eg one polygon for each
    John> country in the world) + associating a value with each
    John> polygon.  Again, great pictures in a few lines of code +
    John> using the collections the speed is pretty good, even with
    John> 3000+ polygons it was all pretty snappy.

    John> I'll see if I can get an example together -- to do this I'll
    John> need to get some un-restricted shape files, but I'll see
    John> what I can do.

That would be great - I'll keep my eyes peeled...

JDH

I'm having trouble getting the alpha keyword to do anything when I use 
the OO interface (as per gtk embeded example).

The attached code demonstrates the problem.

With matlab_test() I get alpha blending as expected, with the 
gtk_embed_test() it seems to be ignored.

Aside from this, I'd just like to say what a great package matplotlib 
is.   I've been using it a lot the last week to plot maps -- first I 
started using pcolor to plot hurricane footprints (I'll see if I can get 
the OK to release some of the plots, pcolor produced some wonderful 
pictures with a few lines of code).

Inspired by this I've also been plotting simple maps by creating 
collections of polygons (eg one polygon for each country in the world) + 
associating a value with each polygon.  Again, great pictures in a few 
lines of code + using the collections the speed is pretty good, even 
with 3000+ polygons it was all pretty snappy.

I'll see if I can get an example together -- to do this I'll need to get 
some un-restricted shape files, but I'll see what I can do.

Many thanks for matplotlib.

John

This is primarily a bug-fix release from 0.65, though a couple of
little features managed to sneak in

 - 4x image speedups for large images

 - figimage bug fixed

 - fixed some bugs which caused the colorbar not to update properly
   when changing colormap interactively

 - refactored axes management to support delaxes, which deletes, as
   opposed to clears, a specified axes.  Default to current axes

 - tkagg's classic and new-fangled toolbars are now embeddable.

 - extended the new set/get introspection features to more classes

 - fixed some tkagg flakiness on win32 regarding unusual uses of show.

 - new cross backend animation idiom in examples/anim.py - use
   interactive mode rather than timers/idle handlers.

 - deferred some initializations in dates and colors modules for
   faster load times.


http://sourceforge.net/projects/matplotlib

Enjoy!

JDH 

>>>>> "seberino" == seberino  <seb...@sp...> writes:

    seberino> I'm trying to make a 2D color plot where the z-axis
    seberino> values show up as different colors for each (x,y) point.
    seberino> I tried to plot the list a+b+c+d using the code snipped
    seberino> below.  I don't understand why this regular grid of
    seberino> points is giving me the weird color plot attached.  Any
    seberino> help would be greatly appreciated.

    seberino> WHY DON't I SEE **SQUARES** OF COLORS IN ATTACHED
    seberino> PLOT???

Because you are not filling your arrays properly.  Print xarray and
yarray in your example and you'll see the problem.  In your example,
xarray is

[[ 1  2  3  4]
 [ 5  6  7  8]
 [ 9 10  1  2]
 [ 3  4  5  6]
 [ 7  8  9 10]
 [ 1  2  3  4]
 [ 5  6  7  8]
 [ 9 10  1  2]
 [ 3  4  5  6]
 [ 7  8  9 10]]

is which is causing the weird plots you observe.

In your script, the problem line is

  xarray.shape = yarray.shape = zarray.shape = xsize, ysize

replace this with  

  xarray.shape = yarray.shape = zarray.shape = ysize, xsize

and you'll get the pcolor you are looking for, I suspect.


JDH

I'm trying to make a 2D color plot where the z-axis values show
up as different colors for each (x,y) point.  I tried to
plot the list a+b+c+d using the code snipped below.
I don't understand why this regular grid of points is giving
me the weird color plot attached.  Any help would be greatly
appreciated.

WHY DON't I SEE **SQUARES** OF COLORS IN ATTACHED PLOT???

a = [(1, 10, 1), (2, 10, 2), (3, 10, 3), (4, 10, 4),  (5, 10, 5),
     (6, 10, 4), (7, 10, 3), (8, 10, 2), (9, 10, 1), (10, 10, 0)]
b = [(1, 20, 1), (2, 20, 2), (3, 20, 3), (4, 20, 4),  (5, 20, 5),
     (6, 20, 4), (7, 20, 3), (8, 20, 2), (9, 20, 1), (10, 20, 0)]
c = [(1, 30, 1), (2, 30, 2), (3, 30, 3), (4, 30, 4),  (5, 30, 5),
     (6, 30, 4), (7, 30, 3), (8, 30, 2), (9, 30, 1), (10, 30, 0)]
d = [(1, 40, 1), (2, 40, 2), (3, 40, 3), (4, 40, 4),  (5, 40, 5),
     (6, 40, 4), (7, 40, 3), (8, 40, 2), (9, 40, 1), (10, 40, 0)]


        # Extracts arrays of values for each axis.

        xarray, yarray, zarray = zip(*plotdata)
        xarray = matplotlib.matlab.array(xarray)
        yarray = matplotlib.matlab.array(yarray)
        zarray = matplotlib.matlab.array(zarray)

        # Finds and sets shapes of arrays.

        ysize = len(sets.Set(yarray))
        xsize = len(yarray) / ysize
        xarray.shape = yarray.shape = zarray.shape = xsize, ysize

        # Create plot.

        matplotlib.matlab.pcolor(xarray, yarray, zarray)


Chris
--
_______________________________________

Christian Seberino, Ph.D.
SPAWAR Systems Center San Diego
Code 2872
49258 Mills Street, Room 158
San Diego, CA 92152-5385
U.S.A.

Phone: (619) 553-9973
Fax  : (619) 553-6521
Email: seb...@sp...
_______________________________________

On Thu, 23 Dec 2004, Steve Chaplin wrote:

[...]

> > P.S: we just looked at backend_gtk.py.
> > Couldn't one safely replace
> >
> >     def draw_lines(self, gc, x, y):
> >         x = x.astype(nx.Int16)
> >         y = self.height*ones(y.shape, nx.Int16) - y.astype(nx.Int16)
> >         self.gdkDrawable.draw_lines(gc.gdkGC, zip(x,y))
> > by
> >
> >     def draw_lines(self, gc, x, y):
> >         x = x.astype(nx.Int16)
> >         y = self.height - y.astype(nx.Int16)
> >         self.gdkDrawable.draw_lines(gc.gdkGC, zip(x,y))
> >
> > ? It might give a small improvement.
> I hope so because I made this change to the code a few weeks ago and it
> is now in the file backend_gdk.py in matplotlib 0.65!
> It looks like you are running an old version of matplotlib.

Well, 0.64 ;-) Last week, before we started with this, there were
no debian packages for 0.65. But now they are,
  http://anakonda.altervista.org/debian/
Sorry for the duplication ...

On Wed, 2004-12-22 at 15:43 +0100, Arnd Baecker wrote:
>From this we get for all **Agg backends that
>   - new_gc
>   - _draw_solid
>   - draw_text
> eat up a major part of the time.
> Another important part is spread in the draw chain
> (for example from 74.3% in  to 47.0 %+10.3 % in GTKAgg).

I've noticed that that new_gc() is called many times (60 times when running 
simple_plot.py) with each call creates a new GraphicsContext instance. I think
it would be more efficient to create just one GC instance and reuse it. It 
would suit the way that the Cairo, PS and possibly SVG and Agg backends 
do their drawing but that might mean completely changing the way the 
matplotlib frontend does its drawing.

> P.S: we just looked at backend_gtk.py.
> Couldn't one safely replace
> 
>     def draw_lines(self, gc, x, y):
>         x = x.astype(nx.Int16)
>         y = self.height*ones(y.shape, nx.Int16) - y.astype(nx.Int16)
>         self.gdkDrawable.draw_lines(gc.gdkGC, zip(x,y))
> 
> 
> by
> 
>     def draw_lines(self, gc, x, y):
>         x = x.astype(nx.Int16)
>         y = self.height - y.astype(nx.Int16)
>         self.gdkDrawable.draw_lines(gc.gdkGC, zip(x,y))
> 
> ? It might give a small improvement.
I hope so because I made this change to the code a few weeks ago and it
is now in the file backend_gdk.py in matplotlib 0.65!
It looks like you are running an old version of matplotlib.

Steve

>>>>> "Chris" == Chris Barker <Chr...@no...> writes:

    Chris> This trick here is that the binary format of a wxBitmap is
    Chris> both platform and instance dependent. The idea, as I
    Chris> understand it, is that a wxBitmap has the same binary
    Chris> format as is needed for the current display, so each
    Chris> platform is different, and it can also be different
    Chris> depending on the depth of the display. Given all this, I
    Chris> doubt you're going to be able to improve on the wx supplied
    Chris> methods for converting from a wxImage to a wxBitmap. (and
    Chris> if you do, contribute it to wx!)

But this might helpful - if we can detect what kind of binary format
wx is using, we can ask agg to convert itself to this format in a
python buffer object and pass this on directly to the wxBitmap.  Agg
has efficient conversion routines from just about any pixel format to
any other.  This would avoid one copy, because we could do (making up
the syntax for copying a buffer into the bitmap

        FigureCanvasAgg.draw(self)
        if display_format=='ZZZ': # made up pixel format
           buffer = self.to_zzz()
           self.bitmap.UpdateFromBuffer(buffer) # made up method
        else:   # fall back on old method
            s = self.tostring_rgb()  
            w = int(self.renderer.width)
            h = int(self.renderer.height)
            image = wxEmptyImage(w,h)
            image.SetData(s)
            self.bitmap = image.ConvertToBitmap()
            self.gui_repaint()

If we could handle the most common cases, it would be a win for most
users.  Any idea how to query the pixel format of the wx display?

    Chris> Does the Agg backend use a binary format compatible with
    Chris> wxImage? If not, that means there are two conversions
    Chris> required, which might be the source of the slowdown.

agg uses an array of unsigned chars r0, b0, g0, a0, r1, b1, g1, a1,
...

What does wxImage use?

JDH

Matt Newville wrote:
> I also agree that the best
> solution is likely to mean converting the Agg image (pixBuffer??)
> into the wx.bitmap in c++. 

This trick here is that the binary format of a wxBitmap is both platform
and instance dependent. The idea, as I understand it, is that a wxBitmap
has the same binary format as is needed for the current display, so each
platform is different, and it can also be different depending on the
depth of the display. Given all this, I doubt you're going to be able to
  improve on the wx supplied methods for converting from a wxImage to a
wxBitmap. (and if you do, contribute it to wx!)

Does the Agg backend use a binary format compatible with wxImage? If
not, that means there are two conversions required, which might be the
source of the slowdown.

-Chris





-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

>>>>> "Dominique" == Dominique Orban <Dom...@po...> writes:

    Dominique> Aha. I just managed to have the stem drawn. My silly
    Dominique> mistake; i thought that to instantiate a Line2D i
    Dominique> needed to pass it (x0, y0) and (x1, y1), but it rather
    Dominique> expects (x0, x1) and (y0, y1). The arrow looks cool
    Dominique> now.

Rather than a line and a polygon, it might be more flexible and
attractive to design the arrow simply as a polygon (you could then
have control of the linewidth, facecolor, and edgewidth, something
like
         
                p0
              /   \
             /     \
            /       \
         p6--p5   p2--p1
             |    |
             |    |
             |    |
             |    |
             |    |    
             p4--p3


    Dominique> My remaining problem is the coordinates. It seems that
    Dominique> matplotlib is positioning the arrow using pixels as
    Dominique> coordinates, from the bottom left corner of the figure
    Dominique> window.

    Dominique> Is my problem a 'transformation' issue?

Yes.  If you derive your class from Artist and add it to the axes with
ax.add_artist (or Patch if you use the polygon approach above and add
it with ax.add_artist), the axes will set the default data
transformation for you, iff and only if you haven't already set the
transform.  There are three default transforms you can choose from 

  fig.transFigure   # 0,0 is lower left of fig and 1,1 is upper right
  ax.transAxes      # 0,0 is lower left of axes and 1,1 is upper right
  ax.transData      # same coordinates as the data in the axes

You have a additional choices with custom transforms.  One approach
would be to set the coordinates of the polygon in points such that the
arrow tip is 0,0 and the width and height are both 1.  You could then
use a scaling and rotation affine where sx, sy are the x and y scales,
and theta is the angle.  If you apply this affine to the arrow, the
width of the arrow would be sx points, the height sy points, and the
angle would be theta and the sucker would still be pointing at 0,0.
One nice feature of transformations is that the let you combine two
coordinate systems by applying a an offset transformation.  In this
case you'd want to apply and offset in data coords and then the arrow
would be pointing at some data location x,y but would still have a
width and height specified in points.  

This is basically how the ticks work.  An x tick is located at an x
location in data coords, a y location in axes coords (eg 0 for bottom
ticks and 1 for top ticks) and a length in points.


Here's an example.  I'm not sure this is the best design.  It might be
more useful to specify a point for the base and a point for the arrowhead,
and draw the arrow between them.  But I am not sure what the best way
to specify the arrow width if you use that design.  In any case, this
will serve as an example you can study to get an idea of how the
transforms work, and you can go from there. It would also be nice to
have some intelligent labeling built it, eg at the arrow base

from pylab import *
from matplotlib.patches import Polygon
from matplotlib.transforms import Affine, Value, zero
import math

class Arrow(Polygon):
    zorder = 4 # these should generally above the things they mark
    def __init__(self, x, y, xytrans, width, height, theta,
                 tipx=2, tipy=0.2):
        """
        Create an arrow pointing at x,y with a base width and total
        height in points

        theta is the arrow rotation - 0 degrees is point up, 90 is
          pointing to the right, 180 is pointing down, 270 is pointing
          left.

        tipx is the tip width and is expressed as fraction of the base width.

        tipy is the tip height expressed as a fraction of the total
          height

        xytrans is the transformation of the x,y coordinate, eg
          ax.transData for data coords and ax.transAxes for axes coords

        """
         
        #        p0
        #      /   \
        #     /     \
        #    /       \
        # p6--p5   p2--p1
        #     |    |
        #     |    |
        #     |    |
        #     |    |
        #     |    |    
        #     p4--p3

        p0 = 0,0
        p1 = tipx*0.5, -tipy
        p2 = 0.5, -tipy
        p3 = 0.5, -1        
        p4 = -0.5, -1
        p5 = -0.5, -tipy
        p6 = -tipx*0.5, -tipy        
        
        verts = p0, p1, p2, p3, p4, p5, p6
        Polygon.__init__(self, verts)


        theta = math.pi*theta/180.
        a = width*math.cos(theta)
        b = -width*math.sin(theta)
        c = height*math.sin(theta)
        d = height*math.cos(theta)
        a,b,c,d = [Value(val) for val in (a,b,c,d)]
        trans  = Affine(a, b, c, d, zero(), zero())
        trans.set_offset((x,y), xytrans)
        self.set_transform(trans)
        


plot([0,1,2], [1,2,3], 'bo', ms=15)
axis([0,3, 0, 4])

ax = gca()
arrow = Arrow(1,2, ax.transData, 10, 100, 135)
set(arrow, fc='g', ec='r', lw=1)
ax.add_patch(arrow)


show()

On Wed, 22 Dec 2004, Dominique Orban apparently wrote:
> Based on John's advice in a previous post about designing an Arrow class
> (http://sourceforge.net/mailarchive/message.php?msg_id=9962785), i have
> restarted from scratch, defining the stem as a Line2D instance and the
> head as a RegularPolygon instance (for now, a triangle).

This will be great.
I hope you will make sure the arrow head is
filled but not stroked, so that the tip ends
up precisely where desired.

Thank you,
Alan Isaac

Hi Matt,

On Tue, 21 Dec 2004, Matt Newville wrote:

[...]

> I agree that the Agg rendering itself does not seem like the
> bottleneck for WXAgg.  Partly because of that, I'm assuming that
> the WXAgg will be good enough for my needs (as opposed to
> completely rewriting backend_wx) and that getting to GTKAgg level
> of performance would be the goal.  I also agree that the best
> solution is likely to mean converting the Agg image (pixBuffer??)
> into the wx.bitmap in c++.  I'm not sure I have a firm grasp on
> how exactly to do that, but it's worth trying.

We did some more profiling (see the other mail) which
confirms that the calls to ConvertTotBitmap and wxEmptyImage
are the main difference to GTKAgg.
The best would be to directly blit the Agg image
onto the wxFrame (however this assumes that these are
of the same type, which we don't know.
If not, the C++ route should be the fastest.
Unfortunately we both don't speak C++ and cannot
help further here).

Best,

Nikolai and Arnd

Hi John,

On Tue, 21 Dec 2004, John Hunter wrote:

> >>>>> "imaginee1" == imaginee1  <ima...@gm...> writes:
>
>     imaginee1> Hi, after spending a nice afternoon profiling the
>     imaginee1> dynamic examples and looking a bit through the code, we
>     imaginee1> can make a few comments on the performace of the wx
>     imaginee1> backends.  We have used kcachegrind to display the
>     imaginee1> results of hotshot - all files can be found under
>     imaginee1> http://www.physik.tu-dresden.de/~baecker/tmp/profiling/
>
> Hi Arnd, thanks for your profiling information - I very much like the
> hotshot graphs!

Nikolai and I were also quite impressed, in particular
because there is another window in which one
can see the corresponding lines of code, including timings
(even down to the wxpython level!).

However, we don't understand the output completely.
One reason certainly is that we don't know the matplotlib
code well enough. Another reason is that there might
be some glitches (either kcachegrind or the
conversion script).

We just did some more profiling,
for TkAgg, GTK, GTKAgg, WX and WXAgg, see:
  http://www.physik.tu-dresden.de/~baecker/tmp/profiling2/

From this we get for all **Agg backends that
  - new_gc
  - _draw_solid
  - draw_text
eat up a major part of the time.
Another important part is spread in the draw chain
(for example from 74.3% in  to 47.0 %+10.3 % in GTKAgg).

Best,

Nikolai and Arnd


P.S: we just looked at backend_gtk.py.
Couldn't one safely replace

    def draw_lines(self, gc, x, y):
        x = x.astype(nx.Int16)
        y = self.height*ones(y.shape, nx.Int16) - y.astype(nx.Int16)
        self.gdkDrawable.draw_lines(gc.gdkGC, zip(x,y))


by

    def draw_lines(self, gc, x, y):
        x = x.astype(nx.Int16)
        y = self.height - y.astype(nx.Int16)
        self.gdkDrawable.draw_lines(gc.gdkGC, zip(x,y))

? It might give a small improvement.

P.P.S: Thanks for mentioning good experiences with GTK under
Windows - we will give it a try.

Aha. I just managed to have the stem drawn. My silly mistake; i thought 
that to instantiate a Line2D i needed to pass it (x0, y0) and (x1, y1), 
but it rather expects (x0, x1) and (y0, y1). The arrow looks cool now.

My remaining problem is the coordinates. It seems that matplotlib is 
positioning the arrow using pixels as coordinates, from the bottom left 
corner of the figure window.

Is my problem a 'transformation' issue?

Thanks,
Dominique