matplotlib-devel Mailing List for matplotlib (Page 2)

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
 Fernando> Charles Moad wrote:
 >> I can't seem to crash TkAgg, but WXAgg and GTKAgg still do.
 >> This seems to not be related to the repr issue from before.
 >> This is all mpl-cvs btw.
 Fernando> OK, I'm afraid this one may require John's help to
 Fernando> debug. I don't know the mpl internals nearly well
 Fernando> enough to even begin to guess where this could be coming
 Fernando> from.
 Fernando> The fact that it's a segfault and not an uncaught
 Fernando> exception means the bug is triggered inside C code.
 Fernando> <TAB> triggers dir() and getattr() calls, which have to
 Fernando> traverse the object's internal dictionary. If the
 Fernando> object is implemented in C/C++, that traversal can do
 Fernando> arbitrary things, including any number of
 Fernando> segfault-inducing manipulations.
The canvas object (eg FigureCanvasGTKAgg) is implemented in python.
It inherits from a gtk base class and an Agg base class. It would be
useful to test whether you get this behavior on the GTK and WX
backends (no Agg). My guess is that this is some is caused by a
threading problem, but can't be sure. This would explain why you see
it with GTKAgg and WXAgg but not TkAgg.
JDH

Charles Moad wrote:
> 	I can't seem to crash TkAgg, but WXAgg and GTKAgg still do. This seems to not 
> be related to the repr issue from before. This is all mpl-cvs btw.
OK, I'm afraid this one may require John's help to debug. I don't know the 
mpl internals nearly well enough to even begin to guess where this could be 
coming from.
The fact that it's a segfault and not an uncaught exception means the bug is 
triggered inside C code. <TAB> triggers dir() and getattr() calls, which have 
to traverse the object's internal dictionary. If the object is implemented in 
C/C++, that traversal can do arbitrary things, including any number of 
segfault-inducing manipulations.
One last thing: do you have Qt installed? If so, can you test with QtAgg as 
your backend? That might help John narrow which parts of the code may or may 
not be involved in this.
Sorry to be so vague...
Cheers,
f

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 Eric> Jeff, I agree with John's comments.
 Eric> Based on a look at the code, but no testing, it looks like
 Eric> your patch is well along the way. I don't have anything
 Eric> ready to merge with it now, but I think I could work on it a
 Eric> bit this weekend, if that would help.
 Eric> One thing I would look at is the handling of the color
 Eric> spacing and the ticks and tick labelling. Allowing linear
 Eric> spacing is a good idea, but we may need more than a single
 Eric> binary kwarg: either two kwargs, or one with string
 Eric> arguments to allow more choice. Specifically, in my
 Eric> experience, it is often useful to give clevels like this:
 Eric> [-100] + frange(-5, 5) + [100]. The middle range may or may
 Eric> not be linear, but the two end points have arbitrary very
 Eric> large absolute values to ensure they will catch the extremes
One suggestions, instead of a linear_spacing kwarg, have something
neutral like "ticks". If ticks is a string like "linearq"
create the ticks accordingly. If it is a sequence, assume it is the
tick locations, eg [-100, -5, -4, ..., 4, 5, 100]. If it is
callable, call it (the latter would support matplotlib.ticker.Locator
instances as well as user functions)
 if is_string_like(ticks):
 if ticks == 'linear':
 theticks = do_something()
 elif ticks == 'log':
 theticks = do_something_else()
 else: 
 raise ValueError("ticks must be log|linear'")
 elif iterable(ticks):
 theticks = ticks
 elif callable(ticks):
 theticks = ticks()
 else:
 raise TypeError("ticks must be a string, a sequence, or callable")
 
 Eric> in the dataset. This is also the case for which Phil is
 Eric> requesting triangles at the ends, I think. In my Matlab
 Eric> code, I don't bother drawing triangles (which have a certain
 Eric> logic and appeal, but would make the colorbar code
 Eric> substantially more complicated); instead I simply make the
 Eric> first and last color patch have the length of the average of
The triangles per-se aren't too hard. Here is an example showing how
to draw them. I haven't used these before so I don't know how to set
their color, but perhaps one of you could plug this in. This would
also have to be adapted to support horizontal colorbars too
 from matplotlib.patches import Polygon
 import matplotlib.numerix as nx
 from pylab import figure, show
 fig = figure()
 ax = fig.add_subplot(111)
 im = ax.imshow(nx.mlab.rand(20,20))
 cax = fig.colorbar(im)
 l,b,w,h = cax.get_position()
 t = b+h
 r = l+w
 midx = l+w/2.
 upper = (l,t), (midx, t+w), (r,t)
 lower = (l,b), (midx, b-w), (r,b)
 pupper = Polygon(upper, fc='red', ec='k', lw=0.5, 
 transform=fig.transFigure)
 plower = Polygon(lower, fc='blue', ec='k', lw=0.5, 
 transform=fig.transFigure)
 fig.patches.append(pupper)
 fig.patches.append(plower)
 show()
 Eric> their immediate neighbors. Then I don't put a tick or label
 Eric> at the ends of the colorbar, but instead start and end at
 Eric> the second and next-to-last clev.
 Eric> Another aspect I customized for Matlab, and would like to do
 Eric> for mpl, is in selecting the size and shape of the colorbar.
 Eric> To my eye, plots look much nicer, and are just as
 Eric> functional, with colorbars smaller in both dimensions than
 Eric> the present default. Any possible change in this aspect,
 Eric> however, would be independent of your changes to support
 Eric> discrete colorbars, and would probably best be left for a
 Eric> separate patch.
Are you aware that the cax arg to colorbar lets you specify the
axes for the colorbar?
JDH

	I can't seem to crash TkAgg, but WXAgg and GTKAgg still do. This seems to not 
be related to the repr issue from before. This is all mpl-cvs btw.
- Charlie
Fernando Perez wrote:
> Charles Moad wrote:
> 
>> I still get an even more random segfault when using the ipython 
>> -pylab option. Here is about the closest thing I can do to reproduce 
>> (most of the time).
>>
>> plot(rand(100))
>> f = get_current_fig_manager()
>> f.canvas.get_width_height()
>> s = f.canvas.tostring_rgb()
>> f.canvas.<tab>Segmentation fault
>>
>> Here is more verbosity if it helps.
> 
> 
> What backend are you using? Can you try with different ones (ipython 
> -pylab adapts automatically, just change your default backend in your 
> ~/.matplotlib/matplotlibrc file). What version of matplotlib are you 
> using?
> 
> Here's what I get, using matplotlib 0.83.2 (official release):
> 
> - TkAgg, QtAgg, WXAgg: no problem, can't reproduce your crash, works 
> normally.
> 
> - GTKAgg: instant crash on my box (even before getting to where it 
> crashes for you):
> 
> In [1]: plot(rand(100))
> ---------------------------------------------------------------------------
> exceptions.SystemError Traceback (most 
> recent call last)
> 
> 
> SystemError: Objects/moduleobject.c:48: bad argument to internal function
> Segmentation fault
> 
> 
> I won't worry about this one, as it may be that I screwed something up 
> in the build, and I don't use GTK ever anyway.
> 
> But knowing what backends trigger your crash will help narrow things down.
> 
> Cheers,
> 
> f

Jeff,
I agree with John's comments.
Based on a look at the code, but no testing, it looks like your patch is 
well along the way. I don't have anything ready to merge with it now, 
but I think I could work on it a bit this weekend, if that would help.
One thing I would look at is the handling of the color spacing and the 
ticks and tick labelling. Allowing linear spacing is a good idea, but 
we may need more than a single binary kwarg: either two kwargs, or one 
with string arguments to allow more choice. Specifically, in my 
experience, it is often useful to give clevels like this: [-100] + 
frange(-5, 5) + [100]. The middle range may or may not be linear, but 
the two end points have arbitrary very large absolute values to ensure 
they will catch the extremes in the dataset. This is also the case for 
which Phil is requesting triangles at the ends, I think. In my Matlab 
code, I don't bother drawing triangles (which have a certain logic and 
appeal, but would make the colorbar code substantially more 
complicated); instead I simply make the first and last color patch have 
the length of the average of their immediate neighbors. Then I don't 
put a tick or label at the ends of the colorbar, but instead start and 
end at the second and next-to-last clev.
Another aspect I customized for Matlab, and would like to do for mpl, is 
in selecting the size and shape of the colorbar. To my eye, plots look 
much nicer, and are just as functional, with colorbars smaller in both 
dimensions than the present default. Any possible change in this 
aspect, however, would be independent of your changes to support 
discrete colorbars, and would probably best be left for a separate patch.
A Matlab example illustrating both the different treatment of 
end-intervals and the altered sizing is 
http://moli.soest.hawaii.edu/nbpalmer/np0305a/cont_a.html
In any case, I don't want to hold you up; you've made great progress, 
and the result looks useful as-is.
Eric
John Hunter wrote:
>>>>>>"Jeff" == Jeff Whitaker <js...@fa...> writes:
> 
> 
> Jeff> Here's a patch against 0.83.2 that modifies colorbar to use
> Jeff> contourf instead of imshow (so that only those colors used
> Jeff> by contourf are shown on the colorbar). It also adds a few
> Jeff> keyword options to colorbar to 1) allow for linear spacing
> Jeff> of colors on the colorbar (even if the contour levels are
> Jeff> not linear), and 2) draw lines on the colorbar between the
> Jeff> individual colors. Eric and Jim: I think you have both been
> Jeff> hacking on colorbar, perhaps we could merge your changes
> Jeff> into this patch? Otherwise, if no one has any objections,
> Jeff> I'll commit this to CVS later this week.
> 
> I haven't tested this but I did read over it and have one minor
> comment
> 
> I tend to avoid catching all exceptions as in
> 
> + try:
> + # mappable image is from contourf
> + clevs = array(mappable.levels.tolist() + [mappable.level_upper])
> + iscontourf = True
> + except:
> + # from imshow or pcolor.
> + iscontourf = False
> + norm = mappable.norm
> + if norm.vmin is None or norm.vmax is None:
> + mappable.autoscale()
> + cmin = norm.vmin
> + cmax = norm.vmax
> + clevs = linspace(cmin, cmax, cmap.N)
> 
> because they can lead to hard to track bugs. I suggest either
> catching an AttributeError or testing explicitly for ContourMappable,
> eg
> 
> if isinstance(mappable, ContourMappable):
> # do something
> elif isinstance(mappable, ScalarMappable):
> # do something else
> else:
> Raise TypeError("don't know how to handle type %s"%type(mappable))
> 
> Thanks,
> JDH

>>>>> "Vinj" == Vinj Vinj <vin...@ya...> writes:
 Vinj> I recently upgraded from 0.8 to 0.83 and now the x labels do
 Vinj> not rotate.
 ...snip...
 Vinj> When I revert back to 0.8 the labels are correctly
 Vinj> displayed. I use the following code for formatting the
 Vinj> xlabels:
Not sure why you are having trouble.
htdocs/screenshots/finance_work2.py is working for me with matplotlib
CVS, 0.83.2 and 0.83
Can you test the finance_work2.py example so at least we're working
with the same code? And since there were a few releases in the 0.83
series, it might help if you post the result of running your code with
the --verbose-helpful example so I know which bugfix release you are
working with. Here's what I get:
peds-pc311:~/python/projects/htdocs/screenshots> python
finance_work2.py -dTkAgg --verbose-helpful
matplotlib data path /usr/share/matplotlib
$HOME=/home/jdhunter
loaded rc file
/home/jdhunter/python/projects/htdocs/screenshots/matplotlibrc
matplotlib version 0.83
verbose.level helpful
interactive is False
platform is linux2
numerix numarray 1.1.1
font search path ['/usr/share/matplotlib']
CONFIGDIR=/home/jdhunter/.matplotlib
loaded ttfcache file /home/jdhunter/.matplotlib/ttffont.cache
backend TkAgg version 8.4
JDH

>>>>> "Helge" == Helge Avlesen <he...@gm...> writes:
 Helge> Hi, this is a very useful option, similar to that of the
 Helge> "axis image" of matlab. a small wish from me: is it also
 Helge> possible to let the option "freeze" the aspect ratio of the
 Helge> figure(s) in question when the window is resized? this is
 Helge> like the matlab behaviour for "axis image", e.g. when the
 Helge> window is enlarged in such a way that the aspect ratio of
 Helge> the window changes, the aspect ratio of the figure(s)
 Helge> remains the same while the increase.
Hey Helge,
This would be useful, but is nontrivial. To make it work, matplotlib
needs to expose the "resize event" across backends so that the Axes
code can connect to it and update itself during the resize. Please
file a support request on the sf site at
http://sourceforge.net/tracker/?group_id=80706&atid=560721
Thanks,
JDH

>>>>> "Jeff" == Jeff Whitaker <js...@fa...> writes:
 Jeff> Here's a patch against 0.83.2 that modifies colorbar to use
 Jeff> contourf instead of imshow (so that only those colors used
 Jeff> by contourf are shown on the colorbar). It also adds a few
 Jeff> keyword options to colorbar to 1) allow for linear spacing
 Jeff> of colors on the colorbar (even if the contour levels are
 Jeff> not linear), and 2) draw lines on the colorbar between the
 Jeff> individual colors. Eric and Jim: I think you have both been
 Jeff> hacking on colorbar, perhaps we could merge your changes
 Jeff> into this patch? Otherwise, if no one has any objections,
 Jeff> I'll commit this to CVS later this week.
I haven't tested this but I did read over it and have one minor
comment
I tend to avoid catching all exceptions as in
+ try:
+ # mappable image is from contourf
+ clevs = array(mappable.levels.tolist() + [mappable.level_upper])
+ iscontourf = True
+ except:
+ # from imshow or pcolor.
+ iscontourf = False
+ norm = mappable.norm
+ if norm.vmin is None or norm.vmax is None:
+ mappable.autoscale()
+ cmin = norm.vmin
+ cmax = norm.vmax
+ clevs = linspace(cmin, cmax, cmap.N)
because they can lead to hard to track bugs. I suggest either
catching an AttributeError or testing explicitly for ContourMappable,
eg
if isinstance(mappable, ContourMappable):
 # do something
elif isinstance(mappable, ScalarMappable):
 # do something else
else:
 Raise TypeError("don't know how to handle type %s"%type(mappable))
Thanks,
JDH

Here's a patch against 0.83.2 that modifies colorbar to use contourf 
instead of imshow (so that only those colors used by contourf are shown 
on the colorbar). It also adds a few keyword options to colorbar to 1) 
allow for linear spacing of colors on the colorbar (even if the contour 
levels are not linear), and 2) draw lines on the colorbar between the 
individual colors. 
Eric and Jim: I think you have both been hacking on colorbar, perhaps 
we could merge your changes into this patch? Otherwise, if no one has 
any objections, I'll commit this to CVS later this week.
Attached also is a test script to exercise the new colorbar features. 
The default behavior should be the same as before.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/CDC R/CDC1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Charles Moad wrote:
> 	I still get an even more random segfault when using the ipython -pylab option. 
> Here is about the closest thing I can do to reproduce (most of the time).
> 
> plot(rand(100))
> f = get_current_fig_manager()
> f.canvas.get_width_height()
> s = f.canvas.tostring_rgb()
> f.canvas.<tab>Segmentation fault
> 
> Here is more verbosity if it helps.
What backend are you using? Can you try with different ones (ipython -pylab 
adapts automatically, just change your default backend in your 
~/.matplotlib/matplotlibrc file). What version of matplotlib are you using?
Here's what I get, using matplotlib 0.83.2 (official release):
- TkAgg, QtAgg, WXAgg: no problem, can't reproduce your crash, works normally.
- GTKAgg: instant crash on my box (even before getting to where it crashes for 
you):
In [1]: plot(rand(100))
---------------------------------------------------------------------------
exceptions.SystemError Traceback (most recent 
call last)
SystemError: Objects/moduleobject.c:48: bad argument to internal function
Segmentation fault
I won't worry about this one, as it may be that I screwed something up in the 
build, and I don't use GTK ever anyway.
But knowing what backends trigger your crash will help narrow things down.
Cheers,
f

	I still get an even more random segfault when using the ipython -pylab option. 
 Here is about the closest thing I can do to reproduce (most of the time).
plot(rand(100))
f = get_current_fig_manager()
f.canvas.get_width_height()
s = f.canvas.tostring_rgb()
f.canvas.<tab>Segmentation fault
Here is more verbosity if it helps.
.....
In [4]:f.canvas.get_width_height
------>f.canvas.get_width_height()
Out[4]:(640, 480)
In [5]:f.canvas.
Display all 294 possibilities? (y or n) <typed "n">
In [5]:f.canvas.to
f.canvas.tostring_argb f.canvas.tostring_rgb
In [5]:s = f.canvas.tostring_rgb()
In [6]:f.canvas.Segmentation fault
Thanks,
	Charlie

Hi,
this is a very useful option, similar to that of the "axis image" of
matlab. a small wish from me: is it also possible to let the option
"freeze" the aspect ratio of the figure(s) in question when the window
is resized? this is like the matlab behaviour for "axis image", e.g.
when the window is enlarged in such a way that the aspect ratio of the
window changes, the aspect ratio of the figure(s) remains the same
while the increase.
Helge

I recently upgraded from 0.8 to 0.83 and now the x
labels do not rotate. 
Here is a chart generated with 0.8 
http://eswap.com/goodlabels.png
and here is a chart generated with 0.83
http://eswap.com/badlabels.png
When I revert back to 0.8 the labels are correctly
displayed. I use the following code for formatting the
xlabels:
# make sure everyone has the same axes limits
set(axLower.get_xticklabels(), 'rotation', 45,
'horizontalalignment', 'right', fontsize=textSize)
Thanks,
VJ

>>>>> "Michael" == Michael Nandris <sui...@ya...> writes:
 Michael> Hi list Is there any voodoo applying axis('equal')?
Are you working with the latest CVS -- Mark Bakker has recently been
working on this function and made substantial improvements. See for
example, examples/axis_equal_demo.py.
JDH

Hi list
Is there any voodoo applying axis('equal')? 
I have tried and it does not equalise the x and y
scales 
There is a 'TODO'
Michael
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

On Sun, 2005年08月14日 at 16:05 -0500, John Hunter wrote:
> >>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes:
> 
> Gregory> Hi John, Hi the list, I almost have finished updating the
> Gregory> fltkAgg, to add the new subplot formatter and the blit
> Gregory> method for fast animation. Everything seems to work fine,
> Gregory> but I still need to do some code clean-up, and before
> Gregory> commiting the changes I have to ask what you think about
> Gregory> the method I used:
> 
> Hi Gregory, Great news. Ken McIvor just emailed me this morning that
> he completed the same with a _wxagg module that he will post shortly.
> That means we have (or will soon have) blit methods for all GUIs
> except Qt and Cocoa (gentle reminder).
It is done, I committed this WE: On my computer (Fedora 4 for x86_64)
there was no problem, let me know if there is any problem on other
platforms...
> Gregory> Now I checked and other backends (qtagg, cocoaagg) now
> Gregory> use RendererAgg::buffer_rgba. If this is ok, I will
> Gregory> update all the calls to pass (0,0) instead of no
> Gregory> arguments, but I wonder if the new methods could not
> Gregory> simplify things for those backends too...
> 
> Yep, this all looks right. I will look into this for gtkagg as well
> tomorrow. It may make rendering to a bbox even faster because gtkagg
> and tkagg may both make an unnecessary copy that your method avoids.
I implemented this, but for qtagg and cocoaagg I just used
RendererAgg::buffer_rgba(0,0) without attempting any optimisation (I
think they do not implement blit at the time being, anyway)
I did not look at gtkagg (no direct use of buffer_rgba it seems, but you
can maybe use the same concept), and also maybe extend this to
Image::buffer_rgba also? I do not know the use case of this one, so I do
not know if it can be usefull or not...
> Gregory> Another remarks is that the animation code seems quite
> Gregory> fragile for the moment: if one do a resize of the output
> Gregory> window, the background copy is not updated correctly and
> Gregory> one have a very interresting effect ;) Well, at leat I
> Gregory> observe that under fltkAgg (my local version supporting
> Gregory> blit) and GTKAgg. tkagg does not do this..because it is
> Gregory> not possible to resize the window during animation (well,
> Gregory> window is resizable but the size of the inside canvas
> Gregory> does not change during this resize...).
> 
> Gregory> I think some extra steps should be performed to make
> Gregory> resize and anim play nicely together (like freezing the
> Gregory> anim during resize, and restarting afterwards with the
> Gregory> correct background...)
> 
> What I do is connect to the new 'draw_event' which is called at the
> end of Figure.draw (no GUI specific event handling required). If you
> set the animated property of the Artist, and then connect your
> background saver to the 'draw_event', it should handle this case.
> Additionally you want to make sure your draw events are processed in
> an idle queue on resizes, etc.
> 
> Check out widgets.Cursor for a complete example using draw_event
> background cacheing, the guts of which are 
> 
> 
> def __init__(self, ax, useblit=False, **lineprops):
> ...snip
> self.canvas.mpl_connect('draw_event', self.clear)
> 
> def clear(self, event):
> 'clear the cursor'
> if self.useblit:
> self.background = self.canvas.copy_from_bbox(self.ax.bbox)
> 
> 
> Does this work for you in GTKAGG and/or FLTK? If everything looks
> good, you may want to update the canonical animation examples in the
> examples directory and on the wiki.
I did that for fltk (see new example animation_blit_fltk.py), it works
nicely! :)
I did not change the gtk example though, but I guess merging the fltk
example tand the animation_blit gtk example, to use the cleaner approach
for GTKAgg will be trivial...I did not change it myself cause I am not
sure you like the coding style I used for the fltk example ;-)
Best regards,
Greg.

The basemap add-on toolkit for matplotlib allows you to plot your data 
on a wide variety of map projections, with coastlines and political 
boundaries.
For an example of what it can do, see See 
http://www.scipy.org/wikis/topical_software/Maps.
This is mainly a bugfix release, with one significant new feature - the 
ability to plot data in ESRI shapefiles (thanks to pyshapelib by 
Bernhard Herzog).
Download it at http://sourceforge.net/projects/matplotlib/
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/CDC1 FAX : (303)497-6449
325 Broadway Web : http://www.cdc.noaa.gov/~jsw
Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124

>>>>> "Michael" == Michael Nandris <sui...@ya...> writes:
 Michael> Well, Xandros ship a python with no distutils.
 Michael> Hmmmmmmmmmm, usefull.
Install distutils rather than trying to work around them. For
example, all the configure, gcc, make stuff you attempted is
unnecessary if you simply use distutils with 'python setup.py build'..
Everything else you are trying will result in a fragmented and
corrupted source. The standard installation techinques will work on
Xandros, I'm willing to wager, and will result in a cleaner, better
system that trying to hack the install. This isn't always true
(solaris and perhaps os x spring to mind) but I have some confidence
that it will be true for your install
 Michael> Anyway, I have a clean reinstall now; but both mpl deb's
 Michael> are broken (see below).
Did you do what I suggested in my last post. Step by step, what was
the output? For example, to the suggested commands
 >>> import matplotlib
 >>> print matplotlib.__version__
What was the output of the apt-get commands? Did you follow the
instructions in the response I sent to matplotlib-users? Did you try a
different GUI backend?
JDH

>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes:
 Gregory> Hi John, Hi the list, I almost have finished updating the
 Gregory> fltkAgg, to add the new subplot formatter and the blit
 Gregory> method for fast animation. Everything seems to work fine,
 Gregory> but I still need to do some code clean-up, and before
 Gregory> commiting the changes I have to ask what you think about
 Gregory> the method I used:
Hi Gregory, Great news. Ken McIvor just emailed me this morning that
he completed the same with a _wxagg module that he will post shortly.
That means we have (or will soon have) blit methods for all GUIs
except Qt and Cocoa (gentle reminder).
 Gregory> Instead of writing a special method taking account of the
 Gregory> bbox for bliting, similar to the agg_to_gtk_drawable, or
 Gregory> a aggcanvas->str conversion like the proposed
 Gregory> aggcanvas.as_rgba_str(bbox), I just changed the method
 Gregory> that I introduced for normal draw in fltkAdd, that rely
 Gregory> on pytho buffer objects to transfer the agg buffer to the
 Gregory> fltk library.
 Gregory> The old method of the Agg backend that was used to get
 Gregory> the buffer object was:
 ....snip...
 Gregory> As fltkAgg is able to use an image source with a pixel
 Gregory> stride (skipping the a of the rgba quatuor) and a line
 Gregory> stride (taking a part of wide w1 from an image of wide
 Gregory> w2), no copy or special method is needed with the new
 Gregory> version of RendererAgg::buffer_rgba...
 Gregory> Now I checked and other backends (qtagg, cocoaagg) now
 Gregory> use RendererAgg::buffer_rgba. If this is ok, I will
 Gregory> update all the calls to pass (0,0) instead of no
 Gregory> arguments, but I wonder if the new methods could not
 Gregory> simplify things for those backends too...
Yep, this all looks right. I will look into this for gtkagg as well
tomorrow. It may make rendering to a bbox even faster because gtkagg
and tkagg may both make an unnecessary copy that your method avoids.
 Gregory> Another remarks is that the animation code seems quite
 Gregory> fragile for the moment: if one do a resize of the output
 Gregory> window, the background copy is not updated correctly and
 Gregory> one have a very interresting effect ;) Well, at leat I
 Gregory> observe that under fltkAgg (my local version supporting
 Gregory> blit) and GTKAgg. tkagg does not do this..because it is
 Gregory> not possible to resize the window during animation (well,
 Gregory> window is resizable but the size of the inside canvas
 Gregory> does not change during this resize...).
 Gregory> I think some extra steps should be performed to make
 Gregory> resize and anim play nicely together (like freezing the
 Gregory> anim during resize, and restarting afterwards with the
 Gregory> correct background...)
What I do is connect to the new 'draw_event' which is called at the
end of Figure.draw (no GUI specific event handling required). If you
set the animated property of the Artist, and then connect your
background saver to the 'draw_event', it should handle this case.
Additionally you want to make sure your draw events are processed in
an idle queue on resizes, etc.
Check out widgets.Cursor for a complete example using draw_event
background cacheing, the guts of which are 
 
 
 def __init__(self, ax, useblit=False, **lineprops):
 ...snip
 self.canvas.mpl_connect('draw_event', self.clear)
 def clear(self, event):
 'clear the cursor'
 if self.useblit:
 self.background = self.canvas.copy_from_bbox(self.ax.bbox)
Does this work for you in GTKAGG and/or FLTK? If everything looks
good, you may want to update the canonical animation examples in the
examples directory and on the wiki.
JDH

Well, Xandros ship a python with no distutils.
Hmmmmmmmmmm, usefull. 
Anyway, I have a clean reinstall now; but both mpl
deb's are broken (see below).
I am (reasonably) confident distutils will fine for
installing mpl, but I think there are 2 final hurdles:
1) agg 	
2) mpl build requires pygtk
	
1) Marcus Gruendler kindly supplied a line for
compiling agg from that list:
	gcc -c -O2 src/*.cpp -Iinclude && ar rc
libantigrain2.a *.o
	
	... after which i assume 'make', 'make install' will
work.
2) ./configure works for pygtk (see below). 
I have stopped here for a rest. phew.
 
I am hoping 'make', 'make install' will ensure pygtk
is picked up when I build matplotlib - any pitfalls? 
... and I only want matplotlib to draw pretty pictures
:)
regards
michael 
 
 
============================= deb files on xandros and
elsewhere are broken ?
====================================================
ONE:
altered /etc/apt/sources.list by adding 
	deb http://anakonda.altervista.org/debian packages/
	deb-src http://anakonda.altervista.org/debian
sources/
	
apt-get update						
apt-get install python-matplotlib
python-matplotlib-doc
apt-get install python-matplotlib
python-matplotlib-doc
Reading Package Lists... Done
Building Dependency Tree... Done
Some packages could not be installed. This may mean
that you have
requested an impossible situation or if you are using
the unstable
distribution that some required packages have not yet
been created
or been moved out of Incoming.
The following information may help to resolve the
situation:
The following packages have unmet dependencies:
 python-matplotlib: Depends: python2.3-matplotlib (=
0.82-1) but it is not going to be installed
E: Broken packages
TWO:
looked for python2.3-matplotlib on xandros networks:
	found python2.3-matplotlib on xandros: package size
is 2.21 MB
	
	After selecting 'install', the xandos dialog box is
visibly broken, and no installation happens. This
happens consistently for all mpl related debs. 
	
	There is a python2.4-matplotlib (albeit with the same
broken dependancy) but no way of upgrading to python
2.4! I *paid* good English pounds
exchanged-at-an-artificially-favourable-rate for
xandros, so I will email them.
	 
================================================================================================================
=========================== output of ./configure for
pygtk is ok
===============================================
maia:/home/mik/src/pygtk-2.4.1# ./configure
checking for a BSD-compatible install...
/usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking for C compiler default output file name...
a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler...
yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none
needed
checking dependency style of gcc... gcc3
checking for bind_textdomain_codeset... yes
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for some Win32 platform... no
checking for native Win32... no
checking for a sed that does not truncate output...
/bin/sed
checking for egrep... grep -E
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for /usr/bin/ld option to reload object
files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
checking how to recognise dependent libraries...
pass_all
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for g++... g++
checking whether we are using the GNU C++ compiler...
yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for g77... no
checking for f77... no
checking for xlf... no
checking for frt... no
checking for pgf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for f90... no
checking for xlf90... no
checking for pgf90... no
checking for epcf90... no
checking for f95... no
checking for fort... no
checking for xlf95... no
checking for ifc... no
checking for efc... no
checking for pgf95... no
checking for lf95... no
checking for gfortran... no
checking whether we are using the GNU Fortran 77
compiler... no
checking whether accepts -g... no
checking the maximum length of command line
arguments... 32768
checking command to parse /usr/bin/nm -B output from
gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking if gcc static flag works... yes
checking if gcc supports -fno-rtti -fno-exceptions...
no
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/bin/ld) supports
shared libraries... yes
checking whether -lc should be explicitly linked in...
no
checking dynamic linker characteristics... GNU/Linux
ld.so
checking how to hardcode library paths into
programs... immediate
checking whether stripping libraries is possible...
yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by g++... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld) supports
shared libraries... yes
checking for g++ option to produce PIC... -fPIC
checking if g++ PIC flag -fPIC works... yes
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (/usr/bin/ld) supports
shared libraries... yes
checking dynamic linker characteristics... GNU/Linux
ld.so
checking how to hardcode library paths into
programs... immediate
checking whether stripping libraries is possible...
yes
appending configuration tag "F77" to libtool
checking for a Python interpreter with version >=
2.3... python
checking for python... /usr/bin/python
checking for python version... 2.3
checking for python platform... linux2
checking for python script directory...
${prefix}/lib/python2.3/site-packages
checking for python extension module directory...
${exec_prefix}/lib/python2.3/site-packages
checking for headers required to compile python
extensions... found
checking for python module thread... yes
checking whether to enable threading in pygtk... yes
checking for pkg-config... /usr/bin/pkg-config
checking for GLIB - version >= 2.4.0... yes (version
2.6.3)
checking for atk >= 1.0.0... yes
checking ATK_CFLAGS... -I/usr/include/atk-1.0
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
checking ATK_LIBS... -Wl,--export-dynamic -latk-1.0
-lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0
checking for pango >= 1.4.0... yes
checking PANGO_CFLAGS... -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
checking PANGO_LIBS... -lpango-1.0 -lgobject-2.0
-lgmodule-2.0 -ldl -lglib-2.0
checking for pkg-config... (cached)
/usr/bin/pkg-config
checking for GTK+ - version >= 2.4.0... yes (version
2.6.2)
checking for GTK+ 2.4... found (version 2.6.2)
checking for libglade-2.0 >= 2.3.6... Package
libglade-2.0 was not found in the pkg-config search
path.
Perhaps you should add the directory containing
`libglade-2.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libglade-2.0' found
checking for Numeric/arrayobject.h... no
checking whether gcc understands -Wall... yes
checking whether gcc understands -std=c9x... yes
checking whether gcc understands
-fno-strict-aliasing... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating pygtk-2.0.pc
config.status: creating codegen/Makefile
config.status: creating gobject/Makefile
config.status: creating gtk/Makefile
config.status: creating docs/Makefile
config.status: creating examples/Makefile
config.status: creating tests/Makefile
config.status: creating codegen/pygtk-codegen-2.0
config.status: creating pygtk.spec
config.status: creating PKG-INFO
config.status: creating config.h
config.status: executing depfiles commands
maia:/home/mik/src/pygtk-2.4.1#
		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

Hi John, Hi the list,
I almost have finished updating the fltkAgg, to add the new subplot
formatter and the blit method for fast animation. Everything seems to
work fine, but I still need to do some code clean-up, and before
commiting the changes I have to ask what you think about the method I
used:
Instead of writing a special method taking account of the bbox for
bliting, similar to the agg_to_gtk_drawable, or a aggcanvas->str
conversion like the proposed aggcanvas.as_rgba_str(bbox), I just changed
the method that I introduced for normal draw in fltkAdd, that rely on
pytho buffer objects to transfer the agg buffer to the fltk library.
The old method of the Agg backend that was used to get the buffer object
was:
Py::Object 
RendererAgg::buffer_rgba(const Py::Tuple& args) {
 //"expose the rendered buffer as Python buffer object";
 
 _VERBOSE("RendererAgg::buffer_rgba");
 
 args.verify_length(0); 
 int row_len = width*4; 
 return Py::asObject(PyBuffer_FromMemory( pixBuffer, row_len*height));
} 
and I just extended it to use only part of the buffer:
Py::Object 
RendererAgg::buffer_rgba(const Py::Tuple& args) {
 //"expose the rendered buffer as Python buffer object, starting from
postion x,y";
 
 _VERBOSE("RendererAgg::buffer_rgba");
 
 args.verify_length(2); 
 int startw = Py::Int(args[0]); 
 int starth = Py::Int(args[1]); 
 int row_len = width*4; 
 int start=row_len*starth+startw*4;
 return Py::asObject(PyBuffer_FromMemory( pixBuffer+start,
row_len*height-start));
} 
As fltkAgg is able to use an image source with a pixel stride (skipping
the a of the rgba quatuor) and a line stride (taking a part of wide w1
from an image of wide w2), no copy or special method is needed with the
new version of RendererAgg::buffer_rgba...
The draw code calls 
Fltk.fl_draw_image(self._source.buffer_rgba(0,0),0,0,int(w),int(h),4,0)
and the blit code 
Fltk.fl_draw_image(self._source.buffer_rgba(x,y),x,y,int(w),int(h),4,int(wo)*4)
Now I checked and other backends (qtagg, cocoaagg) now use
RendererAgg::buffer_rgba. If this is ok, I will update all the calls to
pass (0,0) instead of no arguments, but I wonder if the new methods
could not simplify things for those backends too...
Another remarks is that the animation code seems quite fragile for the
moment: if one do a resize of the output window, the background copy is
not updated correctly and one have a very interresting effect ;) Well,
at leat I observe that under fltkAgg (my local version supporting blit)
and GTKAgg. tkagg does not do this..because it is not possible to resize
the window during animation (well, window is resizable but the size of
the inside canvas does not change during this resize...).
I think some extra steps should be performed to make resize and anim
play nicely together (like freezing the anim during resize, and
restarting afterwards with the correct background...)
Regards,
Greg.

>>>>> "Charles" == Charles Moad <cm...@in...> writes:
 Charles> current cvs. I have a project that I am wanting to use
 Charles> the blitting for the tkagg and I want to test on windows.
 Charles> I don't have a build environment for it. If it is too
 Charles> much trouble, it is not a big deal.
Hey Charles,
If I don't have this to you by 10AM tomorrow, send me an email
reminder.
Thanks,
JDH

On Fri, 2005年08月05日 at 20:28 -0700, Norbert Nemec wrote:
> Currently, when writing a SVG, all raster images produced by
> imshow are
> scaled to a fixed, low resolution. (72dpi?)
> 
> The least I would expect is the 'dpi=' option of savefig to be
> used for
> writing PNGs in the SVG renderer.
I would expect that too. print_figure() ignores the dpi option and
backend_svg.py has a dpi of 72 hardcoded in about 6 different places. A
month ago I tried changing it to respect the dpi argument, the figure
size and graphics shapes were correct but the text came out too small
and positioned incorrectly.
> Even better would be to switch off rescaling completely for
> any vector
> output (EPS and SVG). This would allow optimal quality in
> post-processing.
> 
> I even believe that rescaling to a uniform resolution should
> be an
> option, not the default.
> 
> Has anybody else spent thought on this?
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com 

>>>>> "Charles" == Charles Moad <cm...@in...> writes:
 Charles> I have a project that I am wanting to use the blitting
 Charles> for the tkagg and I want to test on windows. I don't
 Charles> have a build environment for it. If it is too much
 Charles> trouble, it is not a big deal.
OK, the build is at
 http://jdh.uchicago.edu/misc/matplotlib-0.84cvs.win32-py2.4.exe
Thanks for your help on this.
JDH

Hi,
I finally found out what was happening with the method. I was setting the
interval argument for DayLocator to zero by mistake. This is what causes the
infinite loop to happen. 
i.e. the following code will triger the infinite loop:
import matplotlib
from matplotlib.dates import DayLocator
d = DayLocator(interval=0)
from matplotlib.figure import Figure
fig = Figure()
ax = fig.gca()
ax.plot([732165.65085648152, 732166.22956018522], [2, 5])
ax.xaxis.set_major_locator(d)
ax.autoscale_view()
Thanks,
Maria Khomenko