matplotlib-devel Mailing List for matplotlib (Page 542)

> Can fltk use pngs?  I just uploaded some pngs with 
> transparent backgrounds to CVS (revision 1.2)

I will check that, for now I have already a "good enough"(TM) solution,
I shrinked my buttons so that image cover the whole button :-)

> Indicating the button status via relief or whatever is nice, 
> and this is something that can be done on a backend basis.  
> If you , Todd or Steve have ideas on how best to do this for 
> the respective backends, go for it.

Done...I used the relief method, it is probably more portable across
guis and use less screen estate. But idealy a second push to the button
should de-activate the respective action (i.e. toggle mode), is this
done in the current CVS? Well, best way to know is to checkout ;-)

> I updated the way the pointer setting calls in CVS.  Now you 
> only get the special pointers when you are over an axes - 
> otherwise you get the arrow pointer.  I did this by 
> connecting to the motion_notify_event.

Oups! This is good, but it make me realise I did not understand the
motion_notify_event, it mistake it for drag event...
Well, both are interresting, how about adding some events?
For now I have:
  button_press_event
  button_release_event
  key_press_event
  key_release_event
  *button_drag_event
  *button_double_press_event
and I need to add
  motion_notify_event

What do you think of these?

> I would like to have this on all the backends ideally.  I 
> could make a call from the NavigationToolbar2 - 
> set_zoom_overlay(xmin, xmax, ymin,
> ymax) from the motion event.  Would this help you?  Todd , 
> Steve, do you know how to do this in your respective backends?  
> Theoretically, it could be done using matplotlib lines, but 
> then the canvas would have to be redrawn and reblitted 
> dynamically and I don't think the performance is good enough 
> for that in most cases, especially for Tk which is slow for 
> this kind of thing.  Is there a native GUI solution for this 
> on the respective backends?


Hum, the overlay problem is already solved for fltk (although it is not
so clean for the moment, it is done between the fltk event interception
and the event conversion in MplEvent...)It use native fltk blitting, so
no redraw is involved, so you can consider it fully solved on fltk... 


> How is your "reverse zoom" idea different from the right 
> click zoom in/out with the hand/pan button (implemented in 
> gtk and wx but not yet in tk)?  With that button activated, 
> right click drag motions to the left and down zoom out. And 
> what should we call that button anyway? Pan is not a good 
> name since it pans and zooms.

I called it Pan/Zoom (how original ;-) ). 
Reagrding my reverse zoom, in fact it have the same relationship with
right click  for zoom out, than zoom to rectangle has to the right click
for zoom in: the 2 are similar and can perform the same operation, but
in a different manner (right click with pan/zoom center operation on
clicked point, then interractively (well, in the future ;-) ) zoom
in/out, while zoom_to_rect is not interractive, the user select the new
zone that will be expaned to window (zoom in as it is) or that the
window will occupy (new zoom out to rectangle)...Both can be used
depending on the situation and the user preference... 

> No.  I fixed it.  When you get a new CVS checkout (there 
> should be a class Stack defined in backend_bases) make sure 
> it works as expected. Factoring the navigation stack into a 
> dedicated class cleaned up the NavigationToolbar2 base code 
> considerably.

Great, I will checkout the CVS :-)

> I've thought about the master/slave idea before.  There are a 
> number of examples when you want to bind one axes view lim to 
> another.  This could be done with an observer pattern, where 
> axes notify observers when a view lim is set.
> 
> In code, you could call
> 
>   ax1.add_xlim_observer(ax2)
> 
> But I don't know how this would best be handled in the GUI.  
> Also, more often than not you would want changes in ax1 to 
> affect ax2 and vice versa.  Ie, not master-slave but 
> bidirectionally coupled.

Yes, so linking some axes in a group where any new view lim is
broadcasted to all group members...problem would be to defines theses
groups in the gui (easy if one can define only 1 group, and the rest of
axes is independent: it is re-use of the current axes menu, what do you
think of that for a start? It should cover most of the use already :-)

On Fri, 2004-07-23 at 07:12, Gregory Lielens wrote:
> Hello John, Hello Todd,
> 
<SNIP>
> Appart from this, I have other (non-cosmetic ;-) )remarks:
> *In TkAgg, right button Pan (i.e. zoom) does not seem to work, I think
> that's for you Todd ;-)
Got it.  It's checked in.  Thanks.

Todd

>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes:

    Gregory> The new toolbar is great, and new button image too (is
    Gregory> the background transparent, or not? If not and if it is
    Gregory> possible, one minor cosmetic improvement would be to have
    Gregory> transparent background button, they show lighter than my
    Gregory> fltk buttons for now...Well, if it is not possible I
    Gregory> guess I have to overide fltk default to use same color as
    Gregory> the images background)

Can fltk use pngs?  I just uploaded some pngs with transparent
backgrounds to CVS (revision 1.2)

    Gregory> *As mentioned in by someone on the list previously, I
    Gregory> think having button that indicate the status (like toggle
    Gregory> button, or light button, or button that remains pushed)
    Gregory> for Pan/Zoom and Zoom would be great. This way, one can
    Gregory> return to arrow pointer and default (or user set
    Gregory> callback)...For now this seems not possible (or maybe I
    Gregory> did not find the way to do it?) In fltkagg I already put
    Gregory> some light buttons for those, but this behavior is not
    Gregory> activated in toolbar2 so there is not much point doing so
    Gregory> for the moment

Indicating the button status via relief or whatever is nice, and this
is something that can be done on a backend basis.  If you , Todd or
Steve have ideas on how best to do this for the respective backends,
go for it.

I updated the way the pointer setting calls in CVS.  Now you only get
the special pointers when you are over an axes - otherwise you get the
arrow pointer.  I did this by connecting to the motion_notify_event.

    Gregory> *Having the motion_notify_event activated in toolbar 2 to
    Gregory> activate Pan/zoom interactively seems a good idea
    Gregory> (i.e. continous pan/zoom, rcord in the view stack on
    Gregory> release). I can also draw a rectangle overlay when doing
    Gregory> a zoom_to_rect in fltkagg, this will make selection
    Gregory> easier (but I do not know if this is easy to do in other
    Gregory> backends)...also, 

I would like to have this on all the backends ideally.  I could make a
call from the NavigationToolbar2 - set_zoom_overlay(xmin, xmax, ymin,
ymax) from the motion event.  Would this help you?  Todd , Steve, do
you know how to do this in your respective backends?  

Theoretically, it could be done using matplotlib lines, but then the
canvas would have to be redrawn and reblitted dynamically and I don't
think the performance is good enough for that in most cases,
especially for Tk which is slow for this kind of thing.  Is there a
native GUI solution for this on the respective backends?

    Gregory> I'd like to investigate my "reverse"
    Gregory> zoom_to_rect idea, maybe using right click = zoom out to
    Gregory> rectangle/left click = zoom in to rectangle...this way
    Gregory> with 2 buttons we have all navigation possibilities + a
    Gregory> stack view, yay!!!  :-)

How is your "reverse zoom" idea different from the right click zoom
in/out with the hand/pan button (implemented in gtk and wx but not yet
in tk)?  With that button activated, right click drag motions to the
left and down zoom out. And what should we call that button anyway?
Pan is not a good name since it pans and zooms.

    Gregory> *Something that occur in both TkAgg, GTKAgg and FltkAgg
    Gregory> (so it is in toolbar2 base class, I guess) is a
    Gregory> non-conventional stack view behavior (I do not know if it
    Gregory> is intended or not, so I will not scream bug! bug!  too
    Gregory> fast ;-) ): When we navigate with pan/zoom or
    Gregory> zoom_to_rect, views are added in the stack, and one can
    Gregory> go back and further with the previous/next arrows.  But
    Gregory> if one go back to arbitrary position in the stack (with
    Gregory> back or home) and define a new view (pan/zoom again),
    Gregory> this does not replace all the view further in the stack,
    Gregory> but just add this view on top of the stack without
    Gregory> removing any view (hum, this is not so easy to explain
    Gregory> ;-) ).  This is ok in itself, but I find it non-intuitive
    Gregory> cause it does not correspond to a webbrowser or any
    Gregory> undo/redo or back/previous scheme I have encountered
    Gregory> before...So is this intentional?

No.  I fixed it.  When you get a new CVS checkout (there should be a
class Stack defined in backend_bases) make sure it works as expected.
Factoring the navigation stack into a dedicated class cleaned up the
NavigationToolbar2 base code considerably.

    Gregory> Me too :-) I'd like to go further though, I thing the
    Gregory> multiple axes in toolbar1 was a great idea (so do you
    Gregory> Tood, if you keep Axes menu in TkAgg toolbar 2 as a
    Gregory> reminder of the feature...That's what I have done too in
    Gregory> FltkAgg ;-) ) Something like a master/slave idea maybe?
    Gregory> Axes defined as slave of another axe would reproduce the
    Gregory> navigation done in the first one...or a bind notion: all
    Gregory> the axes in the bind group react to navigation within any
    Gregory> axe in the group...Well, these are possible stuff to do
    Gregory> with command line, but a good idea to expose these in the
    Gregory> toolbar remains to be found :-)

I've thought about the master/slave idea before.  There are a number
of examples when you want to bind one axes view lim to another.  This
could be done with an observer pattern, where axes notify observers
when a view lim is set.

In code, you could call

  ax1.add_xlim_observer(ax2)

But I don't know how this would best be handled in the GUI.  Also,
more often than not you would want changes in ax1 to affect ax2 and
vice versa.  Ie, not master-slave but bidirectionally coupled.

JDH

Hello John, Hello Todd,

Toolbar2 is almost operational for FltkAgg... The "Almost" is because I
am currently testing it, but for now no bug has shown ;-) Still no news
from pyfltk guy, though, which will make testing by someone else more
difficult (I can always send my pyfltk, if someone is interrested...)

The new toolbar is great, and new button image too (is the background
transparent, or not? If not and if it is possible, one minor cosmetic
improvement would be to have transparent background button, they show
lighter than my fltk buttons for now...Well, if it is not possible I
guess I have to overide fltk default to use same color as the images
background)

Appart from this, I have other (non-cosmetic ;-) )remarks:
*In TkAgg, right button Pan (i.e. zoom) does not seem to work, I think
that's for you Todd ;-)

*As mentioned in by someone on the list previously, I think having
button that indicate the status (like toggle button, or light button, or
button that remains pushed) for Pan/Zoom and Zoom would be great. This
way, one can return to arrow pointer and default (or user set
callback)...For now this seems not possible (or maybe I did not find the
way to do it?) In fltkagg I already put some light buttons for those,
but this behavior is not activated in toolbar2 so there is not much
point doing so for the moment

*Having the motion_notify_event activated in toolbar 2 to activate
Pan/zoom interactively seems a good idea (i.e. continous pan/zoom, rcord
in the view stack on release). I can also draw a rectangle overlay when
doing a zoom_to_rect in fltkagg, this will make selection easier (but I
do not know if this is easy to do in other backends)...also, I'd like to
investigate my "reverse" zoom_to_rect idea, maybe using right click =
zoom out to rectangle/left click = zoom in to rectangle...this way with
2 buttons we have all navigation possibilities + a stack view, yay!!!
:-) 

*Something that occur in both TkAgg, GTKAgg and FltkAgg (so it is in
toolbar2 base class, I guess) is a non-conventional stack view behavior
(I do not know if it is intended or not, so I will not scream bug! bug!
too fast ;-) ):
When we navigate with pan/zoom or zoom_to_rect, views are added in the
stack, and one can go back and further with the previous/next arrows.
But if one go back to arbitrary position in the stack (with back or
home) and define a new view (pan/zoom again), this does not replace all
the view further in the stack, but just add this view on top of the
stack without removing any view (hum, this is not so easy to explain ;-)
). 
This is ok in itself, but I find it non-intuitive cause it does not
correspond to a webbrowser or any undo/redo or back/previous scheme I
have encountered before...So is this intentional?

*multiple axes
> > Open question is how to handle multiple axes.  I've considered:
> > 
> >   1) all or one checkbox
> > 
> >   2) just reuse old system (menu select) - but how do we deal with
> >      active in menu vs active via mouse.  I find the old way
> >      a bit cumbersome
> > 
> >   3) allow user to select multiple axes with the mouse - maybe make
> >      the selected axes have thicker borders to indicate selection.
> >      Hold down CTRL to select multiple active axes.
> 
> SHIFT?  (Don't know if it's even possible,  just thought 
> that's what is usually done for a multiple select.)
> 
> > 
> >   4) navigation only applies to axes under point (what we 
> have now in
> >      toolbar2)
> > 
> > I'm inclined to 1 or 4.  Users would have the option of toolbar : 
> > classic if they really need the multiple axes feature.  1 
> may be the 
> > best compromise.
> 
> For this afternoon,  I'm going for 4.  :-)  

Me too :-)
I'd like to go further though, I thing the multiple axes in toolbar1 was
a great idea (so do you Tood, if you keep Axes menu in TkAgg toolbar 2
as a reminder of the feature...That's what I have done too in FltkAgg
;-) )
Something like a master/slave idea maybe? Axes defined as slave of
another axe would reproduce the navigation done in the first one...or a
bind notion: all the axes in the bind group react to navigation within
any axe in the group...Well, these are possible stuff to do with command
line, but a good idea to expose these in the toolbar remains to be found
:-)

Regarding the buffer optimisation, I have reimplemented it using double
inheritance and key test in FigureCanvasAgg draw method. it removes the
possible "buffer sharing" bug I mentioned before, so it is up-to-you,
john, to see if this is a better ay to do it: I did not test the
possible performance impact on GTKAgg (I can not see how it can be
nefast, but who knows?), but I have seen a lot of multiple inheritance
in backends so this is not a reason not to do it ;-)

Best regards,

Greg. 

John,

I don't know about your experience with debian, but 'stable' doesn't 
come with the version needed.

If I build freetype from scratch, pygtk would need to be rebuilt as well 
as Gtk etc. etc.
I have done this and it isn't a solution. That leaves me with TkAgg, 
which I don't want.
Wx is not really a solution either, as it is slow and heavy - I have to 
cater for P3-450Mhz style systems

debian is supposed to solve these issues, but
Unfortunately, I can't see a solution to this problem, other than to 
wait for testing to be declared stable in three months after three 
months after three months...

Cheers,
Malte.


John Hunter wrote:

>
>There's no need to upgrade the operating system, but you will need to
>upgrade freetype.  I recommend freetype 2.1.9 - 2.1.7 is required by
>matplotlib, but 2.1.9 fixes some bugs.
>
>With debian, a simple
>
>  > sudo apt-get install freetype freetype-dev 
>
>should do the trick.
>
>
>If your sysadmins won't do this for you, you can always compile a
>version in your home dir.
>  
>

On Thu, 2004-07-22 at 12:50, John Hunter wrote:
> >>>>> "Todd" == Todd Miller <jm...@st...> writes:
> 
>     Todd> Hi John,
>     Todd> Just... gasping... my... way... across... the... finish... line... now.
> 
>     Todd> Toolbar2 is operational for TkAgg and I really like it.
> 
> Good to hear.
> 
> Open question is how to handle multiple axes.  I've considered:
> 
>   1) all or one checkbox
> 
>   2) just reuse old system (menu select) - but how do we deal with
>      active in menu vs active via mouse.  I find the old way
>      a bit cumbersome
> 
>   3) allow user to select multiple axes with the mouse - maybe make
>      the selected axes have thicker borders to indicate selection.
>      Hold down CTRL to select multiple active axes.

SHIFT?  (Don't know if it's even possible,  just thought that's what is
usually done for a multiple select.)

> 
>   4) navigation only applies to axes under point (what we have now in
>      toolbar2)
> 
> I'm inclined to 1 or 4.  Users would have the option of toolbar :
> classic if they really need the multiple axes feature.  1 may be the
> best compromise.

For this afternoon,  I'm going for 4.  :-)  

> 
>     Todd> I changed backend bases a little but don't think it breaks
>     Todd> anything.  I deleted the "button" parameter from a number of
>     Todd> Toolbar2 methods, but since "button" wasn't used and was
>     Todd> followed by *args, I don't think it hurts.
> 
> Agreed.  Vestigial from gtk.
> 
>     Todd> Is now a good time to commit?  Do you want to see a tarball
>     Todd> first?
> 
> Fire when ready.  The world waits with bated breath....

The world can stop waiting...  it's here!

>>>>> "Todd" == Todd Miller <jm...@st...> writes:

    Todd> Hi John,
    Todd> Just... gasping... my... way... across... the... finish... line... now.

    Todd> Toolbar2 is operational for TkAgg and I really like it.

Good to hear.

Open question is how to handle multiple axes.  I've considered:

  1) all or one checkbox

  2) just reuse old system (menu select) - but how do we deal with
     active in menu vs active via mouse.  I find the old way
     a bit cumbersome

  3) allow user to select multiple axes with the mouse - maybe make
     the selected axes have thicker borders to indicate selection.
     Hold down CTRL to select multiple active axes.

  4) navigation only applies to axes under point (what we have now in
     toolbar2)

I'm inclined to 1 or 4.  Users would have the option of toolbar :
classic if they really need the multiple axes feature.  1 may be the
best compromise.

    Todd> I changed backend bases a little but don't think it breaks
    Todd> anything.  I deleted the "button" parameter from a number of
    Todd> Toolbar2 methods, but since "button" wasn't used and was
    Todd> followed by *args, I don't think it hurts.

Agreed.  Vestigial from gtk.

    Todd> Is now a good time to commit?  Do you want to see a tarball
    Todd> first?

Fire when ready.  The world waits with bated breath....

JDH

>>>>> "Malte" == Malte Marquarding <Mal...@cs...> writes:

    Malte> Hi , I can't build matplotlib-0.60.2 under woody.

    Malte> woody doesn't come with th latest freetype-dev It has
    Malte> version '2.0.9'

    Malte> ps And don't tell me not to use woody - our sys admins like
    Malte> to have a retro feeling.

There's no need to upgrade the operating system, but you will need to
upgrade freetype.  I recommend freetype 2.1.9 - 2.1.7 is required by
matplotlib, but 2.1.9 fixes some bugs.

With debian, a simple

  > sudo apt-get install freetype freetype-dev 

should do the trick.


If your sysadmins won't do this for you, you can always compile a
version in your home dir.

Have you tried installing matplotlib via debian:
http://matplotlib.sourceforge.net/installing.html#Debian?  There was a
recent thread on matplotlib-users regarding the debian apt install -
http://sourceforge.net/mailarchive/message.php?msg_id=8961454.

JDH

Last night hayden (jo...@on...) sent me a patch in which he
identified and fixed two leaks in _backend_agg.cpp, one in the
write_png method and one elsewhere.  Spurred on by his successes, I
tracked down and fixed some additional leaks in the _transforms and
ft2font modules.

Using units/memleak_hawaii3.py in CVS for test script, on typical runs
creating hundreds of random, complex figures, I get anywhere from -5
up to 40 bytes per figure.  Since this range is sometimes negative, it
may reflect statistical fluctuation.  This number is down from 400
bytes per figure in 0.60.2 (and 24K in 0.54.2) and is getting into the
"manageably small" range.  Of course, there is always the possibility
of a leak in an untested area, but I'm encouraged....

Lessons for developers (and me):

  * in pycxx extension code, you almost always want to return
    Py::asObject rather than Py::Object.  One exception is returning
    None as Py::Object().  This caused several leaks in the ft2font
    module.

  * Never incref where you meant to decref!  This was the cause of the
    leak in the _transforms module, which had escaped my earlier unit
    tests because I wasn't unit testing the leak of binary operations
    of lazy values.  In the BinOp class, I was incref-ing in the
    destructor.  Very bad...

  * Use freetype 2.1.9 since this fixes some leaks in earlier
    versions.

JDH

    Hello all,

    First I want to apologize for sending this message to both lists, 
but I couldn't decide which one is more appropriate and I would like to 
have an answer as soon as possible. I discovered matplotlib some while 
ago, but it wasn't until recently when I decided to integrate it into 
one of my programs, trying to replace PyPlot that doesn't have enough 
features for me. I downloaded and installed version 0.60.2. Your library 
seemed perfect, until I discovered some strange problems that prevented 
me from using it as this point :( Specifically, I'm reffering to the 
embedding_in_wx2.py example that I found in the 'examples' directory. I 
modified it as follows (sorry for inlining, but I don't know if the 
listserver accepts any attachements at all, I didn't use it before):

=================================================================

#!/usr/bin/env python
"""
An example of how to use wx or wxagg in an application w. or w/o the toolbar
"""

from matplotlib.numerix import arange, sin, pi

import matplotlib

# uncomment the following to use wx rather than wxagg
#matplotlib.use('WX')
#from matplotlib.backends.backend_wx import FigureCanvasWx as FigureCanvas

# comment out the following to use wx rather than wxagg
matplotlib.use('WXAgg')
from matplotlib.backends.backend_wxagg import FigureCanvasWxAgg as 
FigureCanvas

from matplotlib.figure import Figure

from wxPython.wx import *

class Cursor:
    def __init__(self, canvas, ax):
        self.canvas = canvas
        self.ax = ax


    def mouse_move(self, widget, event):
        height = self.ax.figure.bbox.height()
        x, y = event.x, height-event.y

        if self.ax.in_axes(x, y):
            # transData transforms data coords to display coords.  Use
            # the inverse method to transform back to data coords then
            # update the line

            # the cursor position
            x, y =  self.ax.transData.inverse_xy_tup( (x,y) )
            # the view limits
            minx, maxx = self.ax.viewLim.intervalx().get_bounds()
            miny, maxy = self.ax.viewLim.intervaly().get_bounds()

            print 'x=%1.2f, y=%1.2f'%(x,y)


class CanvasFrame(wxFrame):

    def __init__(self):
        wxFrame.__init__(self,None,-1,
                         'CanvasFrame',size=( 900,900 ) )

        self.SetBackgroundColour(wxNamedColor("WHITE"))

        self.figure = Figure( )
        self.axes = self.figure.add_subplot(111)
        t = arange(0.0,3.0,0.01)
        s = sin(2*pi*t)
        c = sin(4*pi*t)

        p = self.axes.fill(t,s,'b',t,c,'g')
        p[ 0 ].set_alpha( 0.2 )
        p[ 1 ].set_alpha( 0.2 )
        #p = self.axes.fill(t,s,'b')
        #p[ 0 ].set_alpha( 0.2 )
        #p[ 1 ].set_alpha( 0.2 )
        #self.axes.plot(t,c,'g')
        self.axes.vlines( [1.5], -1.0, 1.0 )

        self.canvas = FigureCanvas(self, -1, self.figure)

        self.sizer = wxBoxSizer(wxVERTICAL)
        self.sizer.Add(self.canvas, 1, wxTOP | wxLEFT | wxEXPAND)
        self.SetSizer(self.sizer)
        self.SetAutoLayout( True )
#        self.Fit()
        self.sizer.Fit( self )

        cursor = Cursor(self.canvas, self.axes)
        #cursor = SnaptoCursor(canvas, ax, t, s)
        self.canvas.connect('motion_notify_event', cursor.mouse_move)

        #self.add_toolbar()  # comment this out for no toolbar

        # Capture the paint message
        EVT_PAINT(self, self.OnPaint)
        EVT_SIZE( self, self.OnSize)

    def add_toolbar(self):
        self.toolbar = NavigationToolbar(self.canvas, True)
        self.toolbar.Realize()
        if wxPlatform == '__WXMAC__':
            # Mac platform (OSX 10.3, MacPython) does not seem to cope with
            # having a toolbar in a sizer. This work-around gets the buttons
            # back, but at the expense of having the toolbar at the top
            self.SetToolBar(self.toolbar)
        else:
            # On Windows platform, default window size is incorrect, so set
            # toolbar width to figure width.
            tw, th = self.toolbar.GetSizeTuple()
            fw, fh = self.canvas.GetSizeTuple()
            # By adding toolbar in sizer, we are able to put it at the 
bottom
            # of the frame - so appearance is closer to GTK version.
            # As noted above, doesn't work for Mac.
            self.toolbar.SetSize(wxSize(fw, th))
            self.sizer.Add(self.toolbar, 0, wxLEFT | wxEXPAND)
        # update the axes menu on the toolbar
        self.toolbar.update()


    def OnPaint(self, event):
#        self.canvas.draw()
        print "OnPaint"
#        if type( event ) == type( wxEvent ):
        event.Skip()

    def OnSize( self, event ):
        print "OnSize"
        print event.GetSize()
        event.Skip()
#        event.Skip()


class App(wxApp):

    def OnInit(self):
        'Create the main window and insert the custom frame'
        frame = CanvasFrame()
        frame.Show(true)

        return true

app = App(0)
app.MainLoop()

=================================================================

    The example shows just fine at first, but when I try to resize the 
windows it crashes (note that the original example also crashed under 
the same conditions). By "crashes" I mean that it exits with an 
unhandled exception, and Windows shows that the error is in 
_backend_agg.pyd. It also crashes if I change the initial figure size in 
.matplotlibrc (when changing figure.figsize from 8, 6 to 10, 10). I 
tried running in with Python 2.3.2 and Python 2.3.4, with wxPython 
2.4.2.4 and wxPython 2.5.1.5, but the result was the same. I inserted 
some debug statements in backend_wxagg.py and it seems that the crash is 
in 's = agg.tostring_rgb()', the program doesn't reach the line after 
this call. I modified the above code in a number of ways (including 
changing the code for OnPaint and OnSize as the documentation is not 
clear at all about their role and I don't know what I should do in these 
handlers), but I was unable to solve the problem.
    Note that the same example works fine with the simple WX backend, 
but this is no option for me, as I would really need alpha blending, and 
antialiasing wouldn't hurt too.
    Also, I need help with the initial plot size. When I create the plot 
it has very large margins to the parent frame. This is not convenient to 
me, as I'd like to have a plot that is as large as possible and margins 
as small as possible. Is there a way to modify these margins?
    Thank you for your patience in reading this e-mail and please help 
me if you can. I'm not subscribed to either matplotlib-users or 
matplotlib-devel, so please send your replies with a copy to 
bogdanal@b.astral.ro, or at least let me know if I need to be subscribed 
to the list in order to receive your answers regarding this issue.
    Thank you very much for your help.

    Bogdan Marinescu

Hi ,

I can't build matplotlib-0.60.2 under woody.

woody doesn't come with th latest freetype-dev
It has version '2.0.9'

The following error occurs.

src/ft2font.cpp: In method `class Py::Object 
FT2Font::get_ps_font_info(const Py::Tuple &)':
src/ft2font.cpp:811: `PS_FontInfoRec' undeclared (first use this function)
src/ft2font.cpp:811: (Each undeclared identifier is reported only once
src/ft2font.cpp:811: for each function it appears in.)
src/ft2font.cpp:811: parse error before `;'
src/ft2font.cpp:813: `fontinfo' undeclared (first use this function)
src/ft2font.cpp:813: implicit declaration of function `int 
FT_Get_PS_Font_Info(...)'


PS_FontInfoRec is not present in the woody freetype.


ps And don't tell me not to use woody - our sys admins like to have a 
retro feeling.

Cheers,
Malte.

I upgraded agg in cvs to agg 2.1.   Probably best to flush your build
dir before rebuilding.  Let me know if you have any build troubles -
on my system it was totally seamless.

In other news, I've ported the new toolbar and event handling to
wx/wxagg. The new buttons are as follows:

  HOME    : reset all axes to initial view

  BACK    : reset axes to previous view limits in stack

  FORWARD : reset axes to next view limits in stack

  PAN     : with left button press/release pan and with right button
            press/release zoom.  For pan, the coord under point at
            press will be moved to coord under point at release.  For
            zoom, movements to the right will zoom in on x axes and
            movements to the left will zoom out.  Ditto for y and
            up/down.  Amount of zoom will be proportionate to distance
            mouse travels over x and y between press and release.
            Diagonal movements will zoom both accordingly.

  ZOOM_TO_RECT  : self explanatory

  SAVE  : as in classic

The toolbar choice is determined by the new rc param 'toolbar' which
can be None, classic or toolbar2.

Todd, you may want to take a look at porting this to TkAgg and Gregory
to FLTK.  My guess is you (Todd) can do this in half an hour or so
since it's basically a slight generalization of the connect scheme you
came up with.  It may take a bit longer for you Gregory if you haven't
implemented FigureCanvas.connect yet.

The new toolbar class, backend_bases.NavigationToolbar2, does 95% of
the work and basically just uses the backend to load up the GUI
widgets and make the event calls.  I've uploaded several new (slicker)
widget icons to CVS that you should use to make the toolbar -
described below

The derived toolbar must define

    def set_cursor(self, cursor):
        'Set the current cursor to one of the cursors values'
        OPTIONAL

where the cursors are ints defined in backend_bases as

  # cursors
  class Cursors:  #namespace
      HAND, POINTER, SELECT_REGION = range(3)
  cursors = Cursors()

and you can use them (optionally) to set the screen pointer icon
depending on the user tool (eg HAND vs SELECT_REGION).  See
backend_gtk for an example mapping the constants to GTK cursor
constants.
     
    def _init_toolbar(self):

This is where you actually build the GUI widgets (called by __init__).
The  icons home.xpm, back.xpm, forward.xpm, hand.xpm, zoom_to_rect.xpm
and filesave.xpm are standard across backends (there are ppm versions
in CVS also).

You just need to set the callbacks

  home         : self.home
  back         : self.back
  forward      : self.forward
  hand         : self.pan
  zoom_to_rect : self.zoom
  filesave     : self.save_figure

You only need to define the last one - the others are in the base
class implementation.

    def save_figure(self, button):

identical to other toolbar

See backend_bases.FigureCanvasBase.mpl_connect,
backend_bases.FigureCanvasBase.mpl_disconnect and
backend_bases.MplEvent for information on the (slightly modified)
connection methods.  FigureCanvasBase.connect is deprecated and should
warn or do what you think appropriate.

The callback signature is now

  func(event)

rather than 

  func(widget, event)

since the former was GTK specific and I didn't see the logic of
including widgets in GUI neutral callbacks.  Also, the event contains
more information - x and y in display (flipped if nec.) coords, the
axes the pointer is over (if any) and the x and y in data coords if
the pointer is over an axes.  Both wx and gtk implement the connection
wrapper so it should be easy to follow them.

The examples/coords_demo.py is modified to work with the new code.

Some things are not finished yet - right now the navigation only
applies to the axes under point.  I'm still thinking about how this
should be handled.  

JDH

>>>>> "Paul" == Paul Barrett <ba...@st...> writes:

    Paul> False alarm.  It now works - after blowing away the build
    Paul> tree and rebuilding the entire package.

I've seen the same thing - don't know the cause.

JDH

Paul Barrett wrote:
> 
> Beginning yesterday afternoon, the latest version of CVS core dumps on 
> me when using the *Agg backends.  The PS backend is OK.  It looks like 
> the changes that were made to ft2font.cpp/h yesterday are causing the 
> problem.  Any suggestions on where this bug might be occuring?  I'm 
> compiling and running on RH 8.0.

False alarm.  It now works - after blowing away the build tree and rebuilding 
the entire package.

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

Beginning yesterday afternoon, the latest version of CVS core dumps on me when 
using the *Agg backends.  The PS backend is OK.  It looks like the changes that 
were made to ft2font.cpp/h yesterday are causing the problem.  Any suggestions 
on where this bug might be occuring?  I'm compiling and running on RH 8.0.

  -- Paul

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

I've been thinking that the SciPy '04 conference 
http://www.scipy.org/wikis/scipy04/ on September 2-3 might be a good 
opportunity for some of us to meet in person and contribute to our 
favorite plotting library via a code sprint.

Unfortunately, it seems the "official" scipy code sprints have been 
canceled.

However, I'm a post-doc at Caltech, so I could organize a venue 
independent of the official conference.

So:

1) is anyone interested in participating in a matplotlib code sprint?

2) what day is best for you?

By the way, the earlybird registration date has been delayed a bit, so 
there's still time to get the reduced fee.  Furthermore, there are 
apparently several more spots open for speakers, so please consider 
submitting an abstract.

Personally, I probably won't be available in the days immediately before 
the conference (Wednesday, for example), but could participate on the 
Saturday immediately after the conference.  However, although I'll be 
sad to miss it, if Wednesday is best, I think I could arrange for a 
lab-mate to let participants in to the venue.

Cheers!
Andrew

I just checked (after spending all day solving network problem :-() what
effect the re-use of Agg buffer optimisation has on FltkAgg backend:

    Classic TkAgg: 9.98 FPS
    Improved TkAgg: 9.98 FPS
    classic FltkAgg: 16.1 FPS
    Improved FltkAgg: 17.2 FPS

I also installed pyGtk to be able to test the framerate I gor on may
computer:
     Classic GTKAgg: 16 FPS
     Modified GTKAgg (avoid switch backend, which make my re-use of agg
buffer impossible, use multiple inheritance instead): 16 FPS
     Improved modified GTKAgg: 16.8 FPS

And finaly, to have a complete picture, I tried Tk without blitting (as
explained in a previous message)
	classic TkAgg without blit: 14.3 FPS
	improved TkAgg without blit: 16 FPS

There is various strange things in these benchmarks: 
first I was not able to reproduce the (very small but reproductible)
advantage I observed yesterday for Agg buffer re-use optimization in the
TkAgg backend...It is observable in the FltkAgg and TkAgg backend,
though...and even more so in the TkAgg without blitting one...Maybe this
is maked by the blitting time in the normal TkAgg, though, so this does
not disturb me too much...
Next, I do not observe the high performance of the GTKAgg backend here,
on the contrary the FPS it gives me are in line with the Fltk ones, and
even with Tk when we get rid of the slow blitting...This is quite
surprising...

On the other hand, I have less trouble understanding these results than
the higher GTKAgg performance you report, so to be really complete I
tried an bare Agg rendering:
Just use the same example as my light dynamic plot (mode animation), but
with a matplotlib.use("Agg") and a 
while True: 
   updatefig()

loop instead of idle callback...
Here are the timings:
Classic Agg: 19 FPS (or, better said, RenderingPerSecond)
Optimized Agg: 20.55 RPS


So this confirm what I have observed on the various *Agg backends, which
in summary would be:
-Optimization of Agg, to reuse buffer if possible: Gain from 8% to 0%,
depending on the backend (max on Agg, small to non existent on TkAgg).
It depends also on the complexity of the rendering, the gain will be
higher when simple drawings are done, and minimal when very complex
figures are drawn...This could help for memory leak maybe, though...and
as you will see is a very minimal hack...

Performance of the various *Agg backends, using Agg as reference and a
very simple dynamic plot (for the new reuse Agg buffer scheme, current
"new Agg every draw" should be very similar):
 TkAgg: 49% (ouch!)
 TkAgg without blit: 78%
 GTKAgg: 82%
 FltkAgg: 84%

So Fltk and GTK are fast (the 20 % overhead is due to transfer to screen
buffer, double buffering, and callbacks/idle mechanisms, I guess, no way
to get better than that)
TkInter is a slower toolkit, mainly cause of blit, and also for other
reasons it seems.

Only remaining mystery (but it is a big one!) is why you observe very
different things for GTKAgg? Is it a GTK version problem? A compilation
option? This is really surprising, given the bare Agg test give me RPS
in line with my FPS...Only thing I can think of is a option during Agg
compile that decrease the performance of my Agg somehow...
 
You will find included a tar.gz of all the files I modified (including
small examples and my FltkAgg backend - even if it is not too usefull
before pyfltk has been updated)...If you need any more information or
want to discuss this, I would be glad to help :-)

PS: I forward this to matplotlib-devel, without the attachment: I do not
know if the mailinglist would accept such a thing...

The embedding of TrueType fonts in Postscript files has been add to CVS 
during the past week.  This enhancement should work for both regular 
text and math text, so the text that you see on the screen should be the 
same in Postscript. This change should be transparent to all users, i.e. 
no additional font files are needed.  The TTF is encoded on-the-fly and 
embedded in the PS file when it is written.

Please give it a try and let me know of any problems or anomalies.

 -- Paul

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

>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes:

    Gregory> You are right, I should definitely install pygtk on my
    Gregory> system to check that, I wonder how a 3X increase in FPS
    Gregory> is possible: after all, de-activating blit in the TkAgg
    Gregory> produce only a 1.5X increase (and no image of course ;-)

The gtk advantage over tk depends on the example.  For images (eg
for Andrew's dynamic image) the advantage is approx 1.5x.  For the
simple line drawing dyanmic example you posted, it's about 3x.  I
suppose the difference is that in the image example, there is a much
larger, shared computational burden in agg, whereas with the simple
line drawing example the blitting difference is more pronounced.

    Gregory> It could be more important for GTKAgg, if it is closer to
    Gregory> raw Agg speed than TkAgg and FltkAgg...Something to test
    Gregory> would be to use the Agg backend without exporting the
    Gregory> pixmap buffer but doing the drawing, and check how many
    Gregory> draw/second one can have on the examples, to really check
    Gregory> the penalty associated to the different toolkits, and the
    Gregory> maximum gain we can have by reusing Agg buffer instead of
    Gregory> creating one for each draw...Is this doable?

I'm certainly happy to try it.  One last thing you may want to do
before sending in your updates tomorrow is to run backend_driver.py in
the examples subdir to make sure your changes don't create any
problems with the known examples.

    Gregory> In these cases nothing performance wise, in fact the way
    Gregory> you use should me marginally faster (avoiding the
    Gregory> creation/destruction of python buffer objects ).  Python
    Gregory> buffer objects is a way for me to implement the transfer
    Gregory> without copy of the Agg buffer to fltk in more "abstract"
    Gregory> way: no need to implement a c extension that know both
    Gregory> the internals of agg and fltk, I split it using the
    Gregory> python buffer as a standard protocol (buffer objects were
    Gregory> intended for just this use, I think...).  This is not
    Gregory> very important, but it could simplify things if there is
    Gregory> multiple renderer and multiple toolkits to bind...like if
    Gregory> alternative to Agg is implemented (or multiple version of
    Gregory> Agg must be supported)...and I guess that the overhead of
    Gregory> this creation/destruction of python buffer objects is
    Gregory> really negligeable.

Another area it may help is in backend_gtk and backend_wx, which *do*
use string methods to access the agg image buffer.

JDH

> > You are right, I should definitely install pygtk on my 
> system to check 
> > that, I wonder how a 3X increase in FPS is possible: after all, 
> > de-activating blit in the TkAgg produce only a 1.5X 
> increase (and no 
> > image of course ;-) ): something else than Agg must hold Tk 
> (and Fltk) 
> > back then: I have to test the FPS one have without Agg drawing and 
> > blitting, only canvas update, with GTK, Tk and Fltk, to be sure...
> > 
> I guess I'm surprised at that. How are you disabling the 
> blit? If no blit is being done, where else is the time going 
> if not for agg?

In the draw method of the FigureCanvasTkAgg class (in
matplotlib/backends/backend_tkagg.py file), I just commented out the
second line, going from:

def draw(self):
        FigureCanvasAgg.draw(self)
        tkagg.blit(self._tkphoto, self.renderer._renderer, 2)
        self._master.update_idletasks()


To:


def draw(self):
        FigureCanvasAgg.draw(self)
        #tkagg.blit(self._tkphoto, self.renderer._renderer, 2)
        self._master.update_idletasks()

This makes the image dissapear from screen of course, but still draw the
image in the in-memory Agg buffer...and ask the Tk canvas to redraw
itself (allways with the same empty image), I guess...so I indeed
suspect that the Tk canvas updating is causing the slow down somehow...I
will check that tomorrow for sure! 

Greg, puzzled too ;-)

Though I suppose it may simply be in the mechanism that
tk uses to update it's own buffer (it does its own blitting
behind the scenes as I understand it)... 

> 
> You are right, I should definitely install pygtk on my system to check
> that, I wonder how a 3X increase in FPS is possible: after all,
> de-activating blit in the TkAgg produce only a 1.5X increase (and no
> image of course ;-) ): something else than Agg must hold Tk (and Fltk)
> back then: I have to test the FPS one have without Agg drawing and
> blitting, only canvas update, with GTK, Tk and Fltk, to be sure...
> 
I guess I'm surprised at that. How are you disabling the blit?
If no blit is being done, where else is the time going if not
for agg?

Puzzled, Perry

> I didn't see where the optimization was helping - could you 
> clarify? It looks like about a 5% for tkagg and there are no 
> comparisons for the fltkagg with "classic vs optimized"
> 
>   Classic TkAgg: 9.98 FPS
>   Improved TkAgg: 10.6 FPS
>   FltkAgg: 16.7 FPS

I will check the non optimized (ie with no reuse of Agg buffers) FltkAgg
backend tomorrow, but you are right, the improvement are reproductible
but small. The change for reusing buffer is trivial though, and it may
help if there is memory leak...
 
> As you may know, blitting in tk is pretty slow and there 
> doesn't appear to be anything we can do about it short of 
> some platform dependent extension code (which might be worth 
> doing at some point for linux and win32).  With your example 
> I get approx 14 FPS with tkagg on my system and 45 FPS with 
> gtkagg.  My point is that unless there are some fundamental 
> limitations in fltk as there are in tk, you might want to 
> look to gtkagg as a performance benchmark rather than tkagg. 
> gtkagg is typically 3x faster than tkagg for dynamic plots.

You are right, I should definitely install pygtk on my system to check
that, I wonder how a 3X increase in FPS is possible: after all,
de-activating blit in the TkAgg produce only a 1.5X increase (and no
image of course ;-) ): something else than Agg must hold Tk (and Fltk)
back then: I have to test the FPS one have without Agg drawing and
blitting, only canvas update, with GTK, Tk and Fltk, to be sure...

> Please send them in, either to the list or directly to Todd 
> and myself.  Todd will be interested in anything pertaining 
> to tkagg.

Ok, I send the complete relevant files as attachement tomorrow, to you
and Todd.

> I understand the rational behind not creating a 
> new agg buffer object with each draw, but at the same time 
> your numbers seem to suggest that it isn't too important, 
> performance wise.
It could be more important for GTKAgg, if it is closer to raw Agg speed
than TkAgg and FltkAgg...Something to test would be to use the Agg
backend without exporting the pixmap buffer but doing the drawing, and
check how many draw/second one can have on the examples, to really check
the penalty associated to the different toolkits, and the maximum gain
we can have by reusing Agg buffer instead of creating one for each
draw...Is this doable?

> Also, I am not sure about the necessity of 
> creating a python buffer object - perhaps you can explain 
> this a bit more.  tkagg and gtkagg both use the agg rendering 
> buffer directly with no string copy, eg
> 
>   RendererAgg* aggRenderer = static_cast<RendererAgg*>(args[1].ptr());
> 
> 
> 
> //gtk
> 
>     gdk_draw_rgb_32_image(drawable, gc, 0, 0, 
> 			  width, 
> 			  height, 
> 			  GDK_RGB_DITHER_NORMAL,
> 			  aggRenderer->pixBuffer,
> 			  width*4);
> // tk
>     block.pixelPtr =  aggRenderer->pixBuffer;
> 
> where pixBuffer is the agg pixel buffer.
> 
> What does exposing the buffer in the python layer buy you?

In these cases nothing performance wise, in fact the way you use should
me marginally faster (avoiding the creation/destruction of python buffer
objects ). 
Python buffer objects is a way for me to implement the transfer without
copy of the Agg buffer to fltk in more "abstract" way: no need to
implement a c extension that know both the internals of agg and fltk, I
split it using the python buffer as a standard protocol (buffer objects
were intended for just this use, I think...). 
This is not very important, but it could simplify things if there is
multiple renderer and multiple toolkits to bind...like if alternative to
Agg is implemented (or multiple version of Agg must be supported)...and
I guess that the overhead of this creation/destruction of python buffer
objects is really negligeable.

Best regards,

Greg.

>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes:

    Gregory> So it seems my optimisation has an impact, although
    Gregory> moderate...  On the other hand, the copy mechanism induce
    Gregory> some lag in the TkAgg backend, while reusing the buffer
    Gregory> in FltkAgg seems a nice improvement...To check that, I
    Gregory> disabled the copy in the TkAgg (tkagg.blit call), and got
    Gregory> 16.4 FPS).  I think thus my FltkAgg backend has the same
    Gregory> speed as bare Agg, while some optim are maybe possible on
    Gregory> TkAgg (if Tk can reuse an extern buffer, I am a complete
    Gregory> beginner in Tk so maybe my conclusion are invalid, if
    Gregory> there is a flaw in my examples...

I didn't see where the optimization was helping - could you clarify?
It looks like about a 5% for tkagg and there are no comparisons for
the fltkagg with "classic vs optimized"

  Classic TkAgg: 9.98 FPS
  Improved TkAgg: 10.6 FPS
  FltkAgg: 16.7 FPS

As you may know, blitting in tk is pretty slow and there doesn't
appear to be anything we can do about it short of some platform
dependent extension code (which might be worth doing at some point for
linux and win32).  With your example I get approx 14 FPS with tkagg on
my system and 45 FPS with gtkagg.  My point is that unless there are
some fundamental limitations in fltk as there are in tk, you might
want to look to gtkagg as a performance benchmark rather than tkagg.
gtkagg is typically 3x faster than tkagg for dynamic plots.

    Gregory> Depending on what you think of that, I can submit patches
    Gregory> for the Agg optimisation, exposing the Agg buffer as a
    Gregory> python buffer object (allowing buffer sharing instead of
    Gregory> buffer copying, if toolkit support this). For the fltk
    Gregory> backend, I am ready to support it but it should wait
    Gregory> acceptance of some modif I made in the python bindings of
    Gregory> fltk, for now it does not work with stock pyfltk
    Gregory> bindings...

Please send them in, either to the list or directly to Todd and
myself.  Todd will be interested in anything pertaining to tkagg.  I
understand the rational behind not creating a new agg buffer object
with each draw, but at the same time your numbers seem to suggest that
it isn't too important, performance wise.  Also, I am not sure about
the necessity of creating a python buffer object - perhaps you can
explain this a bit more.  tkagg and gtkagg both use the agg rendering
buffer directly with no string copy, eg

  RendererAgg* aggRenderer = static_cast<RendererAgg*>(args[1].ptr());



//gtk

    gdk_draw_rgb_32_image(drawable, gc, 0, 0, 
			  width, 
			  height, 
			  GDK_RGB_DITHER_NORMAL,
			  aggRenderer->pixBuffer,
			  width*4);
// tk
    block.pixelPtr =  aggRenderer->pixBuffer;

where pixBuffer is the agg pixel buffer.

What does exposing the buffer in the python layer buy you?

It is best (for me) for you to submit your changes as complete files
so I can merge / compare with ediff; my dev tree is often out of sync
with the non-devel cvs tree so applying diffs is hard.

Thanks!
JDH

Oups- forgot to include the "light" dynamic example:

#!/usr/bin/env python
"""
An animated image
"""
import sys, time, os, gc
from matplotlib import rcParams
import matplotlib
matplotlib.use("TkAgg")
from matplotlib.matlab import *
import Tkinter as Tk

fig = figure(1)
a = subplot(111)
a = arange(121.0)*2*pi/120.0
dR = 0.1*sin(5*a)
x_0=sin(a)
y_0=cos(a)
line = plot(x_0,y_0)
axis([ -1.5,1.5, -1.5, 1.5 ])


manager = get_current_fig_manager()
cnt = 0
tstart = time.time()
t=0
class loop:
    
    def __init__(self, master):
        self.master = master
        self.updatefig() # start updating
        
    def updatefig(self):
        global t,x_0,y_0, dR, cnt, start,tstart
        t += pi/20
        R=1+sin(t)*dR
        line[0].set_data(R*x_0,R*y_0)
        manager.canvas.draw()
        cnt += 1
        if not cnt%100:
            print 'FPS', 100.0/(time.time() - tstart)
            tstart=time.time()
        self.master.after(1, self.updatefig) 

cnt = 0

loop(manager.canvas._tkcanvas)
show()