matplotlib-devel Mailing List for matplotlib

import matplotlib.pyplot as plt

fig = plt.figure()
axes = fig.add_subplot(1, 1, 1)
for x in (12, -12):
    for y in (12, -12):
        axes.annotate('X', (x, y), xycoords='axes points', 
                      color='r', ha='center', va='center')
plt.show()

On 12/9/10 11:57 PM, Ludwig Schwardt wrote:
> This patch reminded me to ask why the builtin libpng, zlib and
> libfreetype on Mac OS 10.5 and later are not used to build Matplotlib,

It may be because we still want to support OS-X 10.4 .

Also, not everyone has X11 installed (or does everyone now?)

I also notice that they are in: MacOSX10.4u.sdk (under X11) -- so maybe 
the static libs in there could be used.

-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

Chr...@no...

I think I'm on to something -- it seems that text layout information has 
a cyclical reference that prevents the Text object from being freed.

Can you apply the attached patch and let me know if it solves your issue?

Mike

On 12/10/2010 02:19 PM, Russell E. Owen wrote:
> You may have already seen this in the general mailing list, but I've
> found what I think is a serious memory leak in matplotlib 1.0.0: it
> leaks memory every time canvas.draw() is called, at least when using
> TkAgg on unix and Mac.
>
> Admittedly many graphs do not need canvas.draw() to be called repeatedly
> (which I suspect is how it has survived this long). This came up in the
> context of a strip chart widget, where I am changing the x/time axis
> limits regularly and calling canvas.draw() so that the change is visible.
>
> I submitted ticket 3124990 with a very simple demo script:
> <https://sourceforge.net/tracker/?func=detail&atid=560720&aid=3124990&gro
> up_id=80706>
> (you can disable the setting the x limits if you want to see the leak in
> its purest form, but then nothing changes visually on the graph).
>
> I just wanted to be sure folks know about it in hopes somebody might
> have an idea how to fix it. I have not tried any other back ends.
>
> -- Russell
>
>
> ------------------------------------------------------------------------------
> Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
> new data types, scalar functions, improved concurrency, built-in packages,
> OCI, SQL*Plus, data movement tools, best practices and more.
> http://p.sf.net/sfu/oracle-sfdev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>    


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

You may have already seen this in the general mailing list, but I've 
found what I think is a serious memory leak in matplotlib 1.0.0: it 
leaks memory every time canvas.draw() is called, at least when using 
TkAgg on unix and Mac.

Admittedly many graphs do not need canvas.draw() to be called repeatedly 
(which I suspect is how it has survived this long). This came up in the 
context of a strip chart widget, where I am changing the x/time axis 
limits regularly and calling canvas.draw() so that the change is visible.

I submitted ticket 3124990 with a very simple demo script:
<https://sourceforge.net/tracker/?func=detail&atid=560720&aid=3124990&gro
up_id=80706>
(you can disable the setting the x limits if you want to see the leak in 
its purest form, but then nothing changes visually on the graph).

I just wanted to be sure folks know about it in hopes somebody might 
have an idea how to fix it. I have not tried any other back ends.

-- Russell

Hi,

This patch reminded me to ask why the builtin libpng, zlib and
libfreetype on Mac OS 10.5 and later are not used to build Matplotlib,
removing the need to download these extra libraries. I was pleased to
discover that Snow Leopard shipped with libpng and libfreetype as part
of X11, only to find that even my old Leopard installation had them.
I've been successfully building Matplotlib against them on both
platforms. Besides skipping the download step, these libraries have
the advantage of being correct universal binaries, eliminating another
potential stumbling block. The only problem would be if these
libraries were outdated, but I haven't come across any problems yet.

For the record, I set the following environment variables in
~/.profile on Snow Leopard:

    # These compiler flags ensure 32-bit + 64-bit code generation, as
Snow Leopard produces 64-bit code by default
    export MACOSX_DEPLOYMENT_TARGET=10.6
    export CFLAGS="-arch i386 -arch x86_64 -isysroot
/Developer/SDKs/MacOSX10.6.sdk"
    export LDFLAGS="-arch i386 -arch x86_64
-syslibroot,/Developer/SDKs/MacOSX10.6.sdk"
    export FFLAGS="-m32 -m64"

I then build a Matplotlib egg with:

CFLAGS=${CFLAGS}" -I/usr/X11/include -I/usr/X11/include/freetype2"
LDFLAGS=${LDFLAGS}" -L/usr/X11/lib" python setupegg.py bdist_egg

I've been meaning to publish my installation instructions for
numpy/scipy/matplotlib/ipython on Snow Leopard somewhere for quite a
while, but that will have to wait for another day... I've tried to
trim down my installation procedure to the minimum steps that will
guarantee a working system without introducing extra libraries /
Pythons / etc, so there might be some interest in it.

Ludwig