matplotlib-devel Mailing List for matplotlib

Eric Firing wrote:
> Ryan,
> 
> The pcolor implementation is fundamentally unsuited to large arrays. 
> Therefore I made the pcolorfast axes method, which tries to use the 
> fastest available Agg extension code, depending on the characteristics 
> of the spatial grid. If the grid is rectangular and regular in both 
> directions it uses a slight modification of the image code; if it is 
> rectangular but with irregular spacing, it uses the nonuniform image 
> code; and if it is not rectangular it uses the quadmesh code. It sounds 
> like what you need is the quadmesh version, which you can access either 
> via pcolormesh or pcolorfast. Neither is exposed via the pylab or 
> pyplot API at present; both are axes methods. The pcolorfast API also 
> may change slightly in the future; it probably needs a little more work.
Yeah, I think for purposes of plotting radar data, quadmesh is what i need.
> The quadmesh code has problems with masked arrays in the released 
> version of mpl, but not in the svn version. It is *much* faster than 
> pcolor, but may not be fast enough for your needs.
My latest testing with the trunk with both pcolorfast and pcolormesh 
would seem to indicate that it's still a bit too slow for me.
> If you are looking into what sounds like an OpenGL backend, or component 
> to a backend, then the place to start is still probably pcolormesh or 
> pcolorfast, not pcolor.
This is the approach I'm considering. I've been poking around, and 
managed to create something that rendered, but not too well. However 
this was basically modifying the Gtk backend, and I'm sure there are 
some Gtk things that could be replaced. I noticed there are some other 
draw_* methods in other backends that aren't in the gtk, like 
draw_quad_mesh and draw_rectangle. Is there a definitive list 
somewhere? I tried RendererBase in backend_bases, but it did not have 
draw_rectangle.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

A few weeks ago there was a discussion about putting scatter symbols in 
the legend (see 
http://www.nabble.com/Show-shapes-on-scatterplot-legend--to15744380.html).
I would like to implement scatter symbols in the legend, but I am having 
some problems doing so. In the function _get_handles in legend.py, the 
symbol can be placed in the legend by doing something like:
for path in handle._paths:
 xy = path.vertices
p = Polygon(xy)
The problem is that the polygon that gets drawn is the wrong size and 
aspect ratio. It would seem that this would call for some sort of 
scaling or transform to make the symbol the proper size, but I need some 
assistance or a pointer to documentation on how to do this.
Thanks,
Paul Novak

Happend with your commit from version 4979 -> 4989. Who's going to fix 
that ? Whom can I directly contact ?
-------- Original Message --------
Subject: [matplotlib-devel] axes.py scatter doc-bug
Date: 2008年3月12日 12:30:12 +0100
From: Manuel Metz <mm...@as...>
To: mat...@li...
CC: John Hunter <jd...@gm...>
Hi,
the doc-string of the axes scatter method is buggy. Somehow the
svn-conflict messages got committed to the repository:
I mean this
<<<<<<< .working
[...]
=======
[...]
 >>>>>>> .merge-right.r4987
... stuff)
Manuel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Matplotlib-devel mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Thursday 13 March 2008 05:02:36 pm Ted Drain wrote:
> I'm working on improving the plotting speed of one of our applications. As
> part of that, I was looking at how quickly the QtAgg backend is drawing. I
> added some print out's to the backend and noticed that it seems to be
> drawing everything twice. In the code:
>
> backend_qtagg.py: FigureCanvasQTAgg class:
>
> def draw( self ):
> """
> Draw the figure when xwindows is ready for the update
> """
>
> if DEBUG: print "FigureCanvasQtAgg.draw", self
> self.replot = True
> FigureCanvasAgg.draw(self)
> self.repaint( False )
>
>
>
> FigureCanvasAgg.draw() will cause a draw the repaint call will cause a
> draw. If I comment out the FCAgg.draw() call, my application (QtAgg
> embedded in a PyQt program) works fine. I've also run several of the
> various example scripts and they seem to work fine as well. Panning,
> zooming, redraws, resize, and file saving seem to be unaffected.
>
> Does anyone know why the extra draw call might be necessary?
Thank you for pointing this out, Ted. It actually solves a problem I was 
seeing with the qt4agg backend, where the widgets.Cursor crosshairs were not 
being drawn when blitting was disabled.
I removed the lines from qtagg and qt4agg, and saw no problems in the examples 
or my own application, so I checked in the changes - svn 5002.
Darren

Hi all,
I am trying to compile matplotlib under MacOSX 10.5, and I get the
following error message:
src/_image.cpp:842: error: insn does not satisfy its constraints:
(insn 2573 1070 2574 126 agg24/include/agg_color_rgba.h:268 (set
(mem:QI (plus:SI (reg/f:SI 6 bp)
 (const_int -280 [0xfffffffffffffee8])) [0 SR.2990+0 S1 A8])
 (reg:QI 5 di)) 56 {*movqi_1} (nil)
 (nil))
src/_image.cpp:842: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:391
Has anyone seen this before? I have found the following link, but no
solution is indicated:
http://www.nabble.com/internal-compiler-error-on-os-x-with--arch-i386-td14716109.html
Is this a compiler bug, or are there flags I can use to fix the
problem? I'd appreciate any advice.
Thanks,
Stéfan