Adding custom interactive backend

Hi,

I have a modified version of the TkAgg backend, with a few custom
features, and would like to be able to get pylab/matplotlib to use it,
but without having to put the backend code into the matplotlib code
tree.

Is there a way to make matplotlib find and use a "backend_xxxx.py"
which does not reside in matplotlib/backends/   , and without filling
in entries in matplotlib/__init__.py and
matplotlib/backends/__init__.py  ?

Thank you very much.
Regards,
 Urvashi

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Announcing the new WebLab

Hi all,

Thanks for all of the feedback for my early release of WebLab, a web front 
end for Python and Matplotlib. Based on your comments I am releasing a new 
version with the folowing enhancements:

- Works on Windows XP, Linux and Mac OS X
- Released under MIT license
- Completely rehauled user interface (see some nice screenshots in the 
website)
- easy access to matplotlib functionalities
- A simple dialog toolkit for adding interactivity to the program
- syntax highligting text editor
- fully functioning online file manager

Some of the planned features for near future are:
- Data import and viewing utility for CSV or Tab limited file. The data will 
be directly loadable into numpy matrix for easy access
- More built in tutorial, possibly an integration with Crunchy 
(http://code.google.com/p/crunchy/)
- Host the project in Google code website.

You can find all of the goodies here:
http://www.physics.ox.ac.uk/users/santoso/Software.WebLab.html

Enjoy,

Yusdi

_________________________________________________________________

[patch] RegularPolyCollection.get_transformed_patches speed-up

Hi All,

I've attached a patch which optimizes a particular case of the
RegularPolyCollection.get_transformed_patches method. This is
particularly useful when using a picker on a scatter plot with ~40,000
points (as I happen to be doing) and cuts the time spent in this
function from ~4s to ~1s, which accounts for about 50% of the lag in
my particular use case.

Similar improvements might be possible in the N > 1 case, but I don't
have a) a data set or b) the time to work them out with, so hopefully
someone is happy to check in this patch as it stands, as I think the
N==1 is probably the common case.

If there are any problems with the patch let me know and I'll try to
fix it up. It's against latest svn (3262)

Cheers,

Tim

Index: lib/matplotlib/collections.py
===================================================================
--- lib/matplotlib/collections.py	(revision 3262)
+++ lib/matplotlib/collections.py	(working copy)
@@ -153,7 +153,7 @@
         if not self.pickable(): return
         ind = []
         x, y = mouseevent.x, mouseevent.y

Re: [patch] RegularPolyCollection.get_transformed_patches speed-up

Tim,

Based on a *very superficial* quick look, I have two comments:

1) Since the plan is (or was?) to have one more release before 
specializing to numpy-only support, the ".T" won't work at present.

2) In the following (possibly mangled by mailer),

 > +        if Nsizes == 1:
 > +            xy = asarray([xverts, yverts]).T * sizes[0]
 > +            polys = [xy + offset for offset in 
transOffset.seq_xy_tups(self._offsets)]

I think you can gain additional speedup by eliminating the list 
comprehension.  Instead of using seq_xy_tups you can use numerix_xy to 
return a 2-D array (with columns x and y), and simply add that to xy.

Eric

Tim Leslie wrote:
> Hi All,
> 
> I've attached a patch which optimizes a particular case of the
> RegularPolyCollection.get_transformed_patches method. This is
> particularly useful when using a picker on a scatter plot with ~40,000
> points (as I happen to be doing) and cuts the time spent in this
> function from ~4s to ~1s, which accounts for about 50% of the lag in
> my particular use case.
> 

Re: [patch] RegularPolyCollection.get_transformed_patches speed-up

On 5/10/07, Eric Firing <efiring@...> wrote:
> Tim,
>
> Based on a *very superficial* quick look, I have two comments:
>
> 1) Since the plan is (or was?) to have one more release before
> specializing to numpy-only support, the ".T" won't work at present.
>
> 2) In the following (possibly mangled by mailer),
>
>  > +        if Nsizes == 1:
>  > +            xy = asarray([xverts, yverts]).T * sizes[0]
>  > +            polys = [xy + offset for offset in
> transOffset.seq_xy_tups(self._offsets)]
>
> I think you can gain additional speedup by eliminating the list
> comprehension.  Instead of using seq_xy_tups you can use numerix_xy to
> return a 2-D array (with columns x and y), and simply add that to xy.
>

Thanks for the feedback Eric, I'll rework the patch with your comments
in mind. I also just noticed a rather glaring bug, in that I don't
actually have a 'return polys' after I calculate them in the special
case, which is somewhat embarrassing. I'll fix all this up and submit
a new patch later today.

Cheers,

Tim

Re: [patch] RegularPolyCollection.get_transformed_patches speed-up

Tim Leslie wrote:
> On 5/10/07, Eric Firing <efiring@...> wrote:
>> Tim,
>>
>> Based on a *very superficial* quick look, I have two comments:
>>
>> 1) Since the plan is (or was?) to have one more release before
>> specializing to numpy-only support, the ".T" won't work at present.
>>
>> 2) In the following (possibly mangled by mailer),
>>
>>  > +        if Nsizes == 1:
>>  > +            xy = asarray([xverts, yverts]).T * sizes[0]
>>  > +            polys = [xy + offset for offset in
>> transOffset.seq_xy_tups(self._offsets)]
>>
>> I think you can gain additional speedup by eliminating the list
>> comprehension.  Instead of using seq_xy_tups you can use numerix_xy to
>> return a 2-D array (with columns x and y), and simply add that to xy.
>>
> 
> Thanks for the feedback Eric, I'll rework the patch with your comments
> in mind. I also just noticed a rather glaring bug, in that I don't
> actually have a 'return polys' after I calculate them in the special
> case, which is somewhat embarrassing. I'll fix all this up and submit
> a new patch later today.

Tim,

I took a look at the original code in collections.py.  It looks like it 

Re: [patch] RegularPolyCollection.get_transformed_patches speed-up

Tim,

I couldn't resist; here is a numerix version of the method, which I 
committed to svn:

     def get_transformed_patches(self):
         # Shouldn't need all these calls to asarray;
         # the variables should be converted when stored.
         # Similar speedups with numerix should be attainable
         # in many other places.
         verts = asarray(self._verts)
         offsets = asarray(self._offsets)
         Npoly = len(offsets)
         scales = sqrt(asarray(self._sizes)*self._dpi.get()/72.0)
         Nscales = len(scales)
         if Nscales >1:
             scales = resize(scales, (Npoly, 1, 1))
         transOffset = self.get_transoffset()
         xyo = transOffset.numerix_xy(offsets)
         polys = scales * verts + xyo[:, newaxis, :]
         return polys

It is faster even when there are only three polygons; and as the comment 
indicates, it would be even faster with additional numpification of the 
entire class.  (Present version with 3 polys, 161 usecs vs 241 usecs; 
with 1000, 6.4 msec vs 47.3 msec.)

It is also only lightly tested.  I hope I haven't overlooked some 
situation that would work with the old version but not with this one.

Re: [patch] RegularPolyCollection.get_transformed_patches speed-up

Hi Eric,

I just checked out your change and it works another 0.2s faster than
what I had for my example, so I'm more than happy with the final
result. Thanks for taking the time to put my hazy ideas into practice
the right way 

Cheers,

Tim

On 5/10/07, Eric Firing <efiring@...> wrote:
> Tim,
>
> I couldn't resist; here is a numerix version of the method, which I
> committed to svn:
>
>      def get_transformed_patches(self):
>          # Shouldn't need all these calls to asarray;
>          # the variables should be converted when stored.
>          # Similar speedups with numerix should be attainable
>          # in many other places.
>          verts = asarray(self._verts)
>          offsets = asarray(self._offsets)
>          Npoly = len(offsets)
>          scales = sqrt(asarray(self._sizes)*self._dpi.get()/72.0)
>          Nscales = len(scales)
>          if Nscales >1:
>              scales = resize(scales, (Npoly, 1, 1))
>          transOffset = self.get_transoffset()

SaveFig bug in TkAgg backend

Hi,

When the "save" button is used on the matplotlib tkagg toolbar, it
uses the "Tk"  "asksavefilename" object from the "tkFileDialog" class,
to pop up a little window that allows you to select the name and type
of file to save.    This function internally calls "figure.destroy()".
and the currently active figure gets destroyed (but it is still visible
and memory is not freed). The next plot then creates a new figure
window with the same figure._num as the previous.

see...
backend_tkagg.py : line 621
-> class NavigationToolbar2TkAgg ::   def save_figure(...)
(callback for the toolbar.bsave button)

The "asksavefilename" function call, triggers Gcf.destroy().  This can
be seen by placing a print statement in
_pylab_helpers.py : line 16
-> class Gcf :: def destroy(num)

A script to trigger this is attached
Does anyone else see this, and does anyone have a way to fix this ?

Thank you very much !
Regards,
 Urvashi Rau

-------------------------------------------------------------------------

SVG backend bug when called with Latex

Hi all,

the following shows a bug in the backend sate handling of mpl:

plot(range(10))
title(r'Foo $x=1$')
savefig('foo.eps')  # works fine, as expected.
savefig('foo.svg')  # doesn't work, that's OK: not implemented
savefig('foo.eps')  # now, this doesn't work anymore.   That's the bug.

Basically, when the SVG backend fails to properly generate the file
with latex strings, it fails to resstore something in the backend
state, and MPL ends up 'wedged'.  After that point, the only way to
get an EPS plot again seems to be to restart the session.

Cheers,

f

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/