matplotlib

I think it is a good idea to add such a feature in mpl, and I guess it
would better to have some general way to provide backend specific
options.

Actually, I have been using a modified version of mpl which enables to
set the individual ID of the patches (this is only meaningful in case
of the svg backend) in a very similar way that Andrew described. The
purpose of setting ID is to do some postprocessing of the resulting
svg file. A small post about this can be found at

http://abitofpythonabitofastronomy.blogspot.com/2008/10/svg.html

And my approach was also to use GCs. Although I don't quite like this
approach, it seems to be the easiest way because, as far as I know,
the backends in mpl does not know about the artists.

I think we may introduce a new dictionary property to the GC class and
also in the Artist. And modifies draw() methods of Patch and others so
that it use these properties to pass any optioanl information (
"url"or "id") to the backends.

But I'm not sure is if it is a good idea to expose this option (or
"url" in the Andrew's original post)  to the functions in the axes.py.
We can just grab the return value of the "bar" command (which is a
list of patches) and set some backend specific options for each
patches.

Regards,

-JJ



On Wed, Oct 29, 2008 at 6:06 PM, Andrew Stock
<matplotlib_dev@...> wrote:
> Hi,
>
> I have a requirement to make clickable bar charts using the SVG output
> (rather than html maps).
>
> An initial look has suggested that the following changes would be required:
>
> backend_bases.py: Add a url property to GraphicsContextBase
> (defaulting to None, so it's all backwards compatible)
> axes.py: Add a url option to the bar function and pass this on to the
> constructor of the Rectangle object
> patches.py: Pass the url option in the constructor for the Patch
> object to the GraphicsContextBase object created in the draw function
> backends/backend_svg.py: Add check to _draw_svg_element for url set in
> gc. If it is, write out SVG code for xlink.
>
> I can make these changes and (if people think it would be useful)
> contribute the changes back.  However, before I do this, I wanted to
> check whether this is the right approach to take - I'm not experienced
> with the internals of matplotlib and so if there's a better way of
> doing it, I'd be grateful for the advice.
>
> Once I got the bar charts working, I would be interested in possibly
> extending this to other chart types.
>
> Regards
>
> Andrew
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

> Neil Crighton wrote:
>> I noticed on the event handling doc page:
>>
>> matplotlib-devel@...
>>
>> that the draggable rectangle example doesn't work in version 0.98.3.
>> The rectangle class no longer seems to have the xy property.  If you
>> replace the current on_press() method in the example with the code
>> below it seem to work.
>>
>>     def on_press(self, event):
>>         'on button press we will see if the mouse is over us and store
>> some data'
>>         if event.inaxes != self.rect.axes: return
>>
>>         contains, attrd = self.rect.contains(event)
>>         if not contains: return
>>         xy = self.rect.get_x(),self.rect.get_y()
>>         print 'event contains', xy
>>         x0, y0 = xy
>>         self.press = x0, y0, event.xdata, event.ydata
>>

Here's probably a better question to ask than just to fix the example.
Was it intended that the Rectangle.xy attribute disappear?  I couldn't
find it documented in API_CHANGES. It appears that there was just a
change at some point in Michael's transforms work.  If it's considered
desirable to have it back, I'll volunteer to whip up a patch to make it
a property.  If not, let's just make sure we document this in API_CHANGES.

My opinion is that randomly breaking API is always bad, and there's not
much effort involved in fixing it here.  On the other hand, we've
already had 3 with this breakage, and no complaints up until now (and
that's from our own docs :P)

Thoughts?

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Wed, Oct 29, 2008 at 4:00 PM, Ryan May <rmay31@...> wrote:

> Here's probably a better question to ask than just to fix the example.
> Was it intended that the Rectangle.xy attribute disappear?  I couldn't
> find it documented in API_CHANGES. It appears that there was just a
> change at some point in Michael's transforms work.  If it's considered
> desirable to have it back, I'll volunteer to whip up a patch to make it
> a property.  If not, let's just make sure we document this in API_CHANGES.

I have no problem with you adding it back in as a convenience
property.  Can't see the harm.

JDH

Michiel de Hoon wrote:
> I wrote a backend for matplotlib on Mac OS X. This is a native
> backend for Mac OS X

very nice!

> 4) One drawback compared to the existing cocoa-agg backend is that
> the latter allows easy integration of matplotlib into a larger cocoa
> application, whereas my backend only cares about matplotlib.

well, as far as many of us are concerned, matplotlib IS an embeddable 
plotting package. I suppose you could say that your backend only cares 
about pylab.

Is there any possibility to embed it in another app? I know that wx, for 
instance, can pass a Window handle to other libs, so that you can have 
that window managed and drawn by other code, while wx handles the rest 
of the app -- would this kind of thing be possible with your code with 
wx, and Cocoa, and QT, and ? I imagine GTK would be off the table as it 
is using X11, though I suppose if you are using Apple's X11, it could 
even be possible there.

> Whereas matplotlib has a vastly superior range of high-level plotting
>  capabilities, pygist excelled at sheer speed. This was achieved by 
> having three backends (Windows, Mac OS X, X11) written in C for 
> optimal performance,

I'm still curious where all this speed comes from. MPL already uses Agg 
for a lot, and it's generally reported to be as fast as many native 
drawing APIs (though maybe not quartz?)

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@...

Nice work ... and an ambitious effort.

I've gotten it running, and am a bit perplexed by some of the
performance I'm seeing. Specifically, the following bit takes well
over twice as long to run as does WxAgg. Does this align with others'
testing?

The only difference I detect is that the Mac backend puts up a window
on the call to plt.figure, while WxAgg waits until the call to show().

Thanks,
Eric

# for testing macosx backend only
import matplotlib
matplotlib.use('macosx')

import matplotlib.pyplot as plt
f=plt.figure()
import numpy as np
x=np.arange(1e4)
y=np.sin(x)
ax=f.add_subplot(111)
sc=ax.scatter(x,y,c=x**2.0)
plt.show()




On Tue, Oct 28, 2008 at 12:13 PM, Christopher Barker
<Chris.Barker@...> wrote:
> Michiel de Hoon wrote:
>> I wrote a backend for matplotlib on Mac OS X. This is a native
>> backend for Mac OS X
>
> very nice!
>
>> 4) One drawback compared to the existing cocoa-agg backend is that
>> the latter allows easy integration of matplotlib into a larger cocoa
>> application, whereas my backend only cares about matplotlib.
>
> well, as far as many of us are concerned, matplotlib IS an embeddable
> plotting package. I suppose you could say that your backend only cares
> about pylab.
>
> Is there any possibility to embed it in another app? I know that wx, for
> instance, can pass a Window handle to other libs, so that you can have
> that window managed and drawn by other code, while wx handles the rest
> of the app -- would this kind of thing be possible with your code with
> wx, and Cocoa, and QT, and ? I imagine GTK would be off the table as it
> is using X11, though I suppose if you are using Apple's X11, it could
> even be possible there.
>
>> Whereas matplotlib has a vastly superior range of high-level plotting
>>  capabilities, pygist excelled at sheer speed. This was achieved by
>> having three backends (Windows, Mac OS X, X11) written in C for
>> optimal performance,
>
> I'm still curious where all this speed comes from. MPL already uses Agg
> for a lot, and it's generally reported to be as fast as many native
> drawing APIs (though maybe not quartz?)
>
> -Chris
>
>
>
> --
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R            (206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115       (206) 526-6317   main reception
>
> Chris.Barker@...
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Tue, Oct 28, 2008 at 12:24 PM, Eric Bruning <eric.bruning@...> wrote:
> Nice work ... and an ambitious effort.
>
> I've gotten it running, and am a bit perplexed by some of the
> performance I'm seeing. Specifically, the following bit takes well
> over twice as long to run as does WxAgg. Does this align with others'
> testing?

I haven't had a chance to look at the code yet, but I suspect he
hasn't implemented the path collection draw method. If it's not
implemented, we fall back on drawing each path separately, which is a
lot slower.  scatter ultimately triggers a call to
Renderer.draw_path_collection which has a default implementation and a
specialization in backend_agg.

JDH

--- On Tue, 10/28/08, Christopher Barker <Chris.Barker@...> wrote:
> > 4) One drawback compared to the existing cocoa-agg
> >    backend is that the latter allows easy integration
> >    of matplotlib into a larger cocoa application,
> >    whereas my backend only cares about matplotlib.
> 
...
> Is there any possibility to embed it in another app? I know
> that wx, for instance, can pass a Window handle to other
> libs, so that you can have  that window managed and drawn
> by other code, while wx handles the rest of the app --
> would this kind of thing be possible with your code with 
> wx, and Cocoa, and QT, and ?

That is a good idea. I'll check whether it is possible. Basically, if the embedding app can manage a window by passing it the window handle then it should be possible.

> I'm still curious where all this speed comes from. MPL
> already uses Agg 
> for a lot, and it's generally reported to be as fast as
> many native 
> drawing APIs (though maybe not quartz?)
> 
At this point, most of it is coming from having complete control over the event loop, which allows to avoid superfluous calls to draw().

Best,

--Michiel

--- On Tue, 10/28/08, John Hunter <jdh2358@...> wrote:
> I haven't had a chance to look at the code yet, but I
> suspect he
> hasn't implemented the path collection draw method. If
> it's not
> implemented, we fall back on drawing each path separately,
> which is a
> lot slower.  scatter ultimately triggers a call to
> Renderer.draw_path_collection which has a default
> implementation and a
> specialization in backend_agg.
> 
Good point. Indeed I was not aware of the draw_path_collection method and I have not implemented it. I will implement this method and report back with the timings for Eric's example.

Thanks!

--Michiel.

Michiel de Hoon wrote:
> --- On Tue, 10/28/08, Christopher Barker <Chris.Barker@...>
> wrote:
>> I'm still curious where all this speed comes from.

> At this point, most of it is coming from having complete control over
> the event loop, which allows to avoid superfluous calls to draw().

well, what would be really nice is if we could figure out how to get rid 
of some of this superfluous calls to draw(0 in all the back-ends! I have 
noticed a bunch of extras in wxAgg, but had a hard time untangling it all.

Also, OS-X does double buffer itself, so there may be extra work being 
done there is other back-ends -- essentially triple buffering.

oh well.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@...

There's a bug filed for this.  I've looked at it a few times, but I'm 
not sure how the image flipping parameters are "supposed" to work.  
Anyone else want to have a look at this?

https://sourceforge.net/tracker2/?func=detail&aid=2160909&group_id=80706&atid=560720

Mike

Arnar Flatberg wrote:
> Hi
>
> The gradient_bar example flips the bars using svg, pdf and eps backends.
>
> Add
> fig.savefig("gradient_bar.png")
> fig.savefig("gradient_bar.pdf")
> fig.savefig("gradient_bar.eps")
> fig.savefig("gradient_bar.svg")
>
> to gradient_bar.py to reproduce.
>
> Tested with TkAgg backend (pylab: 1.3.0.dev5867 on python 2.5.2).
>
> Arnar
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Tue, Oct 28, 2008 at 4:20 PM, Michael Droettboom <mdroe@...> wrote:

> There's a bug filed for this.  I've looked at it a few times, but I'm not
> sure how the image flipping parameters are "supposed" to work.  Anyone else
> want to have a look at this?
>
>
> https://sourceforge.net/tracker2/?func=detail&aid=2160909&group_id=80706&atid=560720
>

I was not aware of that, thanks Michael. Just to be clear, (in relation to
the filed ticket), the screen image is just fine for my part, its *only*
after saving in any vector graphic format I get a "flipped" image as a
result. In other words, I have an issue with savefig, while the ticket is
concerned with imshow. Perhaps they are obviously related ... then Im sorry
for the noise :-)

Thanks,

Arnar

No problem.  I didn't mean to imply that you should have known you bug 
was a duplicate.  I was mainly pointing it out for other developers to 
keep track of the issue, since I suspect your issue and the one in the 
bug are the same, but that's probably not obvious to most users.

I suspect the fix is as simple as twiddling a single line of code, it's 
just not obvious to me how the image flipping is supposed to work to 
have consistent behavior across backends -- and I hope another developer 
here has a clue...

Thanks for your report,
Mike

Arnar Flatberg wrote:
>
>
> On Tue, Oct 28, 2008 at 4:20 PM, Michael Droettboom <mdroe@... 
> <mailto:mdroe@...>> wrote:
>
>     There's a bug filed for this.  I've looked at it a few times, but
>     I'm not sure how the image flipping parameters are "supposed" to
>     work.  Anyone else want to have a look at this?
>
>     https://sourceforge.net/tracker2/?func=detail&aid=2160909&group_id=80706&atid=560720
>     <https://sourceforge.net/tracker2/?func=detail&aid=2160909&group_id=80706&atid=560720>
>
>
> I was not aware of that, thanks Michael. Just to be clear, (in 
> relation to the filed ticket), the screen image is just fine for my 
> part, its *only* after saving in any vector graphic format I get a 
> "flipped" image as a result. In other words, I have an issue with 
> savefig, while the ticket is concerned with imshow. Perhaps they are 
> obviously related ... then Im sorry for the noise :-)
>
> Thanks,
>
> Arnar
>

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

> I suspect the fix is as simple as twiddling a single line of code, it's 
> just not obvious to me how the image flipping is supposed to work to 
> have consistent behavior across backends -- and I hope another developer 
> here has a clue...

I suspect this is related to the problem described at

http://thread.gmane.org/gmane.comp.python.matplotlib.general/14420

The problem does not seem to be alignment but that the image is rendered
upside down. The PDF backend does

    img.flipud_out()
    # get rgba data of image and write it in the output file
    img.flipud_out()

and if I comment out the flipud_out calls, I get that particular case
right but then the image_origin example is wrong.

Revision 5618 added a flipud_out call to Axes.draw:

            if self.images[0].origin=='upper':
                im.flipud_out()

The log message is:

------------------------------------------------------------------------
r5618 | jdh2358 | 2008-06-20 20:09:12 +0300 (Pe, 20 Kes 2008) | 1 line
Changed paths:
   M /trunk/matplotlib/examples/api/mathtext_asarray.py
   M /trunk/matplotlib/examples/pylab_examples/figimage_demo.py
   M /trunk/matplotlib/lib/matplotlib/axes.py
   M /trunk/matplotlib/lib/matplotlib/backends/backend_gtkagg.py
   M /trunk/matplotlib/lib/matplotlib/figure.py
   M /trunk/matplotlib/src/_gtkagg.cpp
   M /trunk/matplotlib/src/_image.cpp

added origin support for composite images
------------------------------------------------------------------------

I think this was discussed further in some emails between me, Haibao
Tang, and John Hunter, but at least I have been too busy to spend much
time on matplotlib lately. I hope this helps somebody track the bug
down.

Jouni

Michael Droettboom wrote:
> This may not be necessary if we can get a Windows box, but I thought I'd 
> mention it.
> 
> I wrote a distutils extension a couple of years ago to build Windows 
> installers on a Linux box with Mingw32.  This has been working perfectly 
> for nightly builds on my home machine since around September 2007 for a 
> project with much the same build requirements as matplotlib.  It's 
> really easy to install Mingw32 on Debian derivatives (maybe other dists 
> as well.)

Mike,

Thank you!  I had no idea that mingw32 was available as an ubuntu 
package, for example, and never would have thought to look for it.  Now 
I will have to try it out.  Do you know if there is an scons builder 
that uses it?  That might be the sticking point for my non-mpl C code, 
which is now all built with scons.

I think that if your distutils extension works for building mpl for Win 
on a Linux box, then we should use it.  Anything that reduces dependence 
o having an actual Windows machine around is a win.

On second thought, there is one disadvantage: an automated build on a 
Win box could also run an automated test.

I have some dim impression of having seen a caution regarding 
compatibility between mingw extensions and present or future official 
python.org Python builds.  Does this ring any bells?

Eric

> 
> See here:
> 
> http://gamera.svn.sourceforge.net/viewvc/gamera/trunk/gamera/mingw32_cross_compile.py?revision=1066&view=markup 
> 
> 
> Mike
> 
> John Hunter wrote:
>> On Mon, Oct 27, 2008 at 4:09 PM, Eric Firing <efiring@...> wrote:
>>
>>  
>>> None that I know of.  It would certainly be nice if we had the release
>>> package-building completely automated; or automated daily svn builds 
>>> of the
>>> Win and OSX packages. Since I don't work with either Win or OSX, I don't
>>> know how hard this would be to set up.
>>>     
>>
>> Nightly builds would be excellent -- Charlie, to what extent do you
>> think this is feasible from a scripting perspective?  Ie, ignoring the
>> hardware side for a minute, and assuming we had access to a build farm
>> with OS X and win32, how hard would it be to setup a build bot for
>> nightly builds?
>>
>> JDH
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's 
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great 
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the 
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Matplotlib-devel@...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>   
>

Eric Firing wrote:
> Michael Droettboom wrote:
>> This may not be necessary if we can get a Windows box, but I thought 
>> I'd mention it.
>>
>> I wrote a distutils extension a couple of years ago to build Windows 
>> installers on a Linux box with Mingw32.  This has been working 
>> perfectly for nightly builds on my home machine since around 
>> September 2007 for a project with much the same build requirements as 
>> matplotlib.  It's really easy to install Mingw32 on Debian 
>> derivatives (maybe other dists as well.)
>
> Mike,
>
> Thank you!  I had no idea that mingw32 was available as an ubuntu 
> package, for example, and never would have thought to look for it.  
> Now I will have to try it out.  Do you know if there is an scons 
> builder that uses it?  That might be the sticking point for my non-mpl 
> C code, which is now all built with scons.
No idea.  Haven't spent much time with scons myself.
>
> I think that if your distutils extension works for building mpl for 
> Win on a Linux box, then we should use it.  Anything that reduces 
> dependence o having an actual Windows machine around is a win.
>
> On second thought, there is one disadvantage: an automated build on a 
> Win box could also run an automated test.
True.  But there is always wine -- though I fear my head would start to 
spin.  I'll admit that the advantages of cross-compiling can quickly be 
outweighed by the complexity of debugging and testing.
>
> I have some dim impression of having seen a caution regarding 
> compatibility between mingw extensions and present or future official 
> python.org Python builds.  Does this ring any bells?
It does.  I haven't had problems up to Py2.5 -- but I don't know what's 
coming in that respect, and I don't closely follow Python-on-Windows 
development.

Mike
>
> Eric
>
>>
>> See here:
>>
>> http://gamera.svn.sourceforge.net/viewvc/gamera/trunk/gamera/mingw32_cross_compile.py?revision=1066&view=markup 
>>
>>
>> Mike
>>
>> John Hunter wrote:
>>> On Mon, Oct 27, 2008 at 4:09 PM, Eric Firing <efiring@...> 
>>> wrote:
>>>
>>>  
>>>> None that I know of.  It would certainly be nice if we had the release
>>>> package-building completely automated; or automated daily svn 
>>>> builds of the
>>>> Win and OSX packages. Since I don't work with either Win or OSX, I 
>>>> don't
>>>> know how hard this would be to set up.
>>>>     
>>>
>>> Nightly builds would be excellent -- Charlie, to what extent do you
>>> think this is feasible from a scripting perspective?  Ie, ignoring the
>>> hardware side for a minute, and assuming we had access to a build farm
>>> with OS X and win32, how hard would it be to setup a build bot for
>>> nightly builds?
>>>
>>> JDH
>>>
>>> ------------------------------------------------------------------------- 
>>>
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's 
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win 
>>> great prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in 
>>> the world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Matplotlib-devel@...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>   
>>
>

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

This is now fixed in SVN r6341.

Sorry for the inconvenience.

Mike

John Hunter wrote:
> On Mon, Oct 27, 2008 at 8:49 PM, Fernando Perez <fperez.net@...> wrote:
>
>   
>> src/_tkagg.cpp: In function 'int PyAggImagePhoto(void*, Tcl_Interp*,
>> int, char**)':
>> src/_tkagg.cpp:134: error: no match for 'operator*' in
>> '*aggRenderer->RendererAgg::renderingBuffer'
>> error: command 'gcc' failed with exit status 1
>>
>> John, this is on bic, in case you want to have a look.
>>     
>
> I saw this too, and emailed Michael off list earlier.  He committed a
> significant cleanup earlier of backend agg to reduce the number of
> heap allocations, and somehow tkagg got out of whack, at least on some
> platforms.
>
> JDH
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA