matplotlib-devel Mailing List for matplotlib

Hi Alex,
On Friday 17 February 2006 18:48, Alex Gontmakher wrote:
> Here it goes again. And sorry for the delay, I was busy with other
> things, will catch up...
> Yes, I believe it does not conflict with the savefig's
> landscape-vs-portrait handling. Some of the EPS viewers need this flag
> in order to show the plot in its original orientation (read: heads up).
>
> In addition, I find the code in lines 1049-1053 of bakend_ps.py somewhat
> strange: in my understanding, landsape means that the plot's "up"
> direction is oriented to the left, i.e., the plot is rotated 90CCW. This
> has nothing to do with the plot's width and height. However, that's not
> my code I wouldn't like to fix that myself without knowing the original
> author's intent. Comments?
I'm not the original maintainer of the postscript backend, but I agree that 
those lines were strange. I just committed my changes to cvs, 
portrait/landscape orientation should be better supported now.
Darren

Works perfectly using the cvs version!
Great!
Thanks again,
David
2006年2月21日, Steve Chaplin <ste...@ya...>:
> The previous fix was not quite right.
> self._need_redraw =3D True
> should come before
> if GTK_WIDGET_DRAWABLE(self):
>
> It is now (hopefully) fixed in CVS.
>
> regards,
> Steve
>
>

On Mon, 2006年02月20日 at 20:38 -0800,
mat...@li... wrote:
> Hi,
> No more traceback with the matplolib cvs version. 
> However, I observe now some strange behavior. 
> I join a new example code.
> When you launch the script and press replot button (circle should
> become a line in both tab), then switch to the second tab everything
> ok. But back to the first tab and press replot (line should become a
> circle in both tab), switch to the second tab... still see a line. If
> you use the "pan" tool in the toolbar and move a bit the graph then
> the figure is the updated and become a circle.
> 
> Regards,
> 
> David
The previous fix was not quite right.
 self._need_redraw = True
should come before
 if GTK_WIDGET_DRAWABLE(self):
It is now (hopefully) fixed in CVS.
regards,
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com 

>>>>> "Tom" == Tom Denniston <tom...@al...> writes:
 Tom> I am generating a few hundred graphs and doing so takes on
 Tom> the order of about 10-15 minutes. Which seems to me rather
 Tom> slow. When I profile my code it identifies the calls to
 Tom> get_yticklabels and get_xticklabels as taking over 90% of the
 Tom> time. This seems strange but my calls to these functions are
 Tom> merely a sort round about way of setting the font size of the
 Tom> axis tick labels and suppressing the text for the
 Tom> xticklabels. Is there a more efficient and cleaner way to do
 Tom> this? artist.setp(axes.get_yticklabels(), visible=True,
 Tom> fontsize=7) artist.setp(axes.get_xticklabels(),
 Tom> visible=False)
This is a known performance bottleneck. There are two reasons it is
slow. Every tick label is handled as an independent object, when they
in most cases share most of their properties (font size, orientation)
and so could be better handled as a TextCollection, which does not
exist yet. The second reason is that the text layout engine is doing
layout for newline separated strings with an arbitrary rotation for
every tick label, which is almost never used. So some special case
optimizations to handle the no rotation, no newline text instances
(basically just bypass the layout machinery) would help a lot here.
Are you using matplotlib mathtext also, by chance? This slows things
down a bit too, though is better in recent versions.
JDH

>>>>> "Andrew" == Andrew Straw <str...@as...> writes:
 Andrew> It goes deeper -- even Figure.add_axes() returns an old
 Andrew> Axes instance if the rect given has been seen before. I'd
 Andrew> argue that people delving into the OO innards of
 Andrew> matplotlib should be able to handle keeping a reference to
 Andrew> instances of Axes they've created. Can we change this
 Andrew> behavior or would it cause massive breakage somewhere?
This used to be handled in pylab helpers, but because there was some
desire for OO matplotlib and pylab to have the same functionality, and
to simplify the code, I moved the current axes handling into the
figure class. The core of the current axes handling is what is
causing the problem you have.
Did you see this in the add_axes docstring
 Eg, if you want two axes that are
 otherwise identical to be added to the axes, make sure you give them
 unique labels:
 add_axes((l,b,w,h), label='1')
 add_axes((l,b,w,h), label='2')
Ie, the problem and the workaround are explicitly mentioned in the
add_axes docs, and since the functionality is fairly core, I am
inclined to leave it. One might do
for i,data enumerate(mydata):
 a = fig.add_axes(somerect, label='axes%d'%i)
and then update some rect later.
JDH