matplotlib-devel Mailing List for matplotlib

As there was no explicit objection, I just submit this to the trunk.
The change in Axes class is rather minor, and I hope others don't
mind.
I added two examples. The examples are rather lengthy, because they
are actually helper classes that I have been playing with (and it is
not well documented).
Here is screenshots.
http://dl.getdropbox.com/u/178748/mpl_aux/axes_divider.png
http://dl.getdropbox.com/u/178748/mpl_aux/axes_grid.png
I hope others find this useful.
Regards,
-JJ
On Wed, Dec 17, 2008 at 1:06 AM, Jae-Joon Lee <lee...@gm...> wrote:
> Hello,
>
> I'm thinking about slightly modifying the draw() method of the Axes
> class, so that user can optionally
> calculate the position of the axes at drawing time. It may be
> considered as a general version of the apply_aspect() method.
>
> For example, instead of "self.apply_aspect()" call in the draw
> function, we may put something like below.
>
> if self._axes_locator:
> self._axes_locator(self, renderer)
> else:
> self.apply_aspect()
>
> where self._axes_locator is a (user-supplied) callable object which
> takes the axes itself and the renderer as arguments.
> I have been running a similar version of this, and I found it quite
> helpful especially when drawing images. Here are a few of my use
> cases.
>
> * colorbar (or any kind of axes) whose location is adjusted to match
> the image location (which is calculated on the fly with apply_aspect).
> * grid of images (of same size) with fixed space between them.
>
> I guess the needed change is not significant and I don't think it will
> interfere with other things of Axes class.
> So, how do others think?
>
> Regards,
>
> -JJ
>

On Fri, Dec 19, 2008 at 6:50 PM, Sandro Tosi <mo...@de...> wrote:
> On Fri, Dec 19, 2008 at 18:47, Ondrej Certik <on...@ce...> wrote:
>> On Fri, Dec 19, 2008 at 6:34 PM, Sandro Tosi <mo...@de...> wrote:
>>> This is fixed in the latest release (0.98.4 or in 0.98.5); I'm working
>>> on uploading it Debian, together with John and Michael (and all dev
>>> team), to have a feasable release.
>>
>> Ah, I didn't know you are on the mpl dev team as well. That's great.
>
> Oh no no: I bother them for something, and they (to force me to
> silence) release a fix :D
Ah I see. The next level is that they'll force you to fix it yourself. :)
Ondrej

On Fri, Dec 19, 2008 at 18:47, Ondrej Certik <on...@ce...> wrote:
> On Fri, Dec 19, 2008 at 6:34 PM, Sandro Tosi <mo...@de...> wrote:
>> This is fixed in the latest release (0.98.4 or in 0.98.5); I'm working
>> on uploading it Debian, together with John and Michael (and all dev
>> team), to have a feasable release.
>
> Ah, I didn't know you are on the mpl dev team as well. That's great.
Oh no no: I bother them for something, and they (to force me to
silence) release a fix :D
Cheers,
-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Dec 19, 2008, at 7:52 AM, John Hunter wrote:
> Could you post the script you are using to do the profiling? The call
> to subplot/plot/bar should not trigger a draw, unless "interactive" is
> set to True
>
> http://matplotlib.sourceforge.net/users/shell.html
>
> Interactive is not the best word, but it is the rc parameter meaning
> "you are using mpl from the interactive prompt and want every pyplot
> command to update the plot". If the macosx backend is not doing this
> it should. If tkagg is issuing draw commands on pyplot commands when
> interactive is False, it is a bug that we should be able to fix.
The interactive backends (wx, tk, gtk) all handle draw_idle in a way
which delays the drawing until there are no more commands to run.
By changing draw_if_interactive to use draw_idle instead of draw,
wouldn't this automatically smooth over the performance issues without
the user having to toggle interactive in their scripts?
 - Paul

On Fri, Dec 19, 2008 at 2:20 AM, Michiel de Hoon <mjl...@ya...> wrote:
>> This looks great -- in particular I am intrigued by the
>> final timing results which show your backend 12 times
>> faster than tkagg. I am not sure where this speedup is
>> coming from -- do you have some ideas?
>
> In this example, I am drawing 16 subplots in a 4x4 grid. With Tkagg, I am noticing that the first few subplots appear quickly, but subsequent subplots get slower and slower. I think that this is due to how the event loop works. In my understanding, tkagg redraws the window when a subplot is added. So to draw subplot 16, tkagg also needs to redraw subplots 1..15, causing the progressive slowdown. The native backend draws all 16 at once, and draws each of them only once. Using plot() instead of bar() doesn't really make a difference; the same slowdown happens there with the agg backends.
Could you post the script you are using to do the profiling? The call
to subplot/plot/bar should not trigger a draw, unless "interactive" is
set to True
 http://matplotlib.sourceforge.net/users/shell.html
Interactive is not the best word, but it is the rc parameter meaning
"you are using mpl from the interactive prompt and want every pyplot
command to update the plot". If the macosx backend is not doing this
it should. If tkagg is issuing draw commands on pyplot commands when
interactive is False, it is a bug that we should be able to fix.
Thanks,
JDH

On Fri, Dec 19, 2008 at 1:49 AM, Michiel de Hoon <mjl...@ya...> wrote:
> It appears that the 98.5.2 tarball is missing one file for the native Mac OS X backend: src/_macosx.m is missing. The other file (lib/matplotlib/backends/backend_macosx.py) is present.
Yep, I forgot to modify the MNIFEST.in to include *.m files from src.
This is fixed and new files have been uploaded. Thanks for catching
this.
JDH

> This looks great -- in particular I am intrigued by the
> final timing results which show your backend 12 times
> faster than tkagg. I am not sure where this speedup is
> coming from -- do you have some ideas?
In this example, I am drawing 16 subplots in a 4x4 grid. With Tkagg, I am noticing that the first few subplots appear quickly, but subsequent subplots get slower and slower. I think that this is due to how the event loop works. In my understanding, tkagg redraws the window when a subplot is added. So to draw subplot 16, tkagg also needs to redraw subplots 1..15, causing the progressive slowdown. The native backend draws all 16 at once, and draws each of them only once. Using plot() instead of bar() doesn't really make a difference; the same slowdown happens there with the agg backends.
In principle, it should be possible to avoid these redraws with the agg and other backends, but it depends on how much of the underlying event loop is exposed by Tkinter/gtk/wx. Basically, instead of calling figManager.show() from draw_if_interactive(), we'd have to call it from inside the Tkinter/gtk/wx event loop just before the event loop starts waiting for events. However, it depends on whether the functionality to insert calls into the event loop is available on Tkinter/gtk/wx.
> Since the new macosx backend was released in 0.98.5, I also
> need to decide whether this patch belongs on the branch, and hence
> will get pushed out as early as today in a bugfix release when some
> changes JJ and Michael are working on are ready, or the trunk, in
> which case it could be months.
> .... I'm in favor of branch, ...
Me too. :-).
--Michiel
> 
> JDH
> 
> 
> On Tue, Dec 16, 2008 at 6:08 PM, Michiel de Hoon
> <mjl...@ya...> wrote:
> > Dear all,
> >
> > I have now implemented the draw_path_collection,
> draw_quad_mesh, and draw_markers methods in the Mac OS X
> native backend (see patch 2179017 at
> >
> http://sourceforge.net/tracker/?func=detail&atid=560722&aid=2179017&group_id=80706).
> Some timings are below. In terms of raw drawing speed, the
> native backend can be either faster or slower than agg. On
> the other hand, the native backend can be considerably
> faster if the agg backend uses many calls to draw(); the
> native backend can avoid these superfluous because it has
> complete control over the event loop (see the third example
> below).
> > # Timings in seconds
> > # n Mac OS X TkAgg
> > # 2 2 6
> > # 3 3 23
> > # 4 5 66
> >
> >
 

It appears that the 98.5.2 tarball is missing one file for the native Mac OS X backend: src/_macosx.m is missing. The other file (lib/matplotlib/backends/backend_macosx.py) is present.
--Michiel.
--- On Thu, 12/18/08, John Hunter <jd...@gm...> wrote:
> From: John Hunter <jd...@gm...>
> Subject: [matplotlib-devel] 98.5.2 tarball and OS X binaries up
> To: "matplotlib development list" <mat...@li...>
> Date: Thursday, December 18, 2008, 12:26 PM
> Just wanted to let you know that I posted the 0.98.5.2
> tarball and OS
> X binaries at
> 
> https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194&release_id=646644
> 
> I'm going to hold off an announcement to the users list
> until Charlie
> gets the win32 binaries up.
> 
> JDH
> 
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in
> Las Vegas, Nevada.
> The future of the web can't happen without you. Join
> us at MIX09 to help
> pave the way to the Next Web now. Learn more and register
> at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel