matplotlib-devel Mailing List for matplotlib

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.