matplotlib-users Mailing List for matplotlib (Page 1429)

I found another issue with plot_date. Dont have a simple example yet, and 
hope that this is something 'obvious' and I don't have to bother.

I attach two images showing the issue. I can go get rid of the weird scaling 
in 'bad.png'  when I do:

ax.viewLim.intervalx().set_bounds(minXValueImPlotting, maxXValueImPlotting)

after:

ax.autoscale_view()

I also noticed a couple of things inside axes.py, that might be wrong:

1)
    def get_ylim(self):
        "Get the y axis range [ymin, ymax]"
        return self.viewLim.intervalx().get_bounds()

should that intervax() be intervaly() ??

2) panx() and pany() are different as well, but perhaps they should be..

Changin these two things does not fix my problem so it has to be something 
else - hoping a simple typo. Will try to write a demo script that shows 
this... (I have matplotlib wrapped into other code so its not really a 
copy/paste-all type deal).

Peter


John Hunter wrote:

>>>>>>"Michael" == Michael Hauser <ha...@na...> writes:
>
>
>    Michael> Hello, I am having a problem with plot_date. I keep
>    Michael> getting the error:
>
>    Michael> Am I missing something obvious?
>
>No, there is a bug in plot_date in setting the tick formatter object.
>I didn't find this in any of my test or example scripts since all
>those explicitly set the formatter and hence hid the bug.  At the end
>of the Axes.plot_date function in matplotlib.axes, replace
>
>        self.xaxis.set_minor_locator(formatter)
>
>with        self.xaxis.set_major_formatter(formatter)
>
>and you'll be good to go.  Note however that there is a problem with
>your script in that the length of your x and y arrays must be the
>same.  After making the changes above, try
>
>from datetime import datetime
>from matplotlib.dates import EpochConverter
>from matplotlib.matlab import *
>
>times = [1084195314, 1084195375, 1084195436, 1084195497, 1084195557]
>vals = [10.2, 11.1, 8.7, 12.1, 12.2]
>converter = EpochConverter()
>ax = subplot(111)
>plot_date(times, vals, converter)
>savefig('test')
>show()
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the
>one installation-authoring solution that does it all. Learn more and
>evaluate today! http://www.installshield.com/Dev2Dev/0504
>_______________________________________________
>Matplotlib-users mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

>>>>> "Michael" == Michael Hauser <ha...@na...> writes:

    Michael> Hello, I am having a problem with plot_date. I keep
    Michael> getting the error:

    Michael> Am I missing something obvious?

No, there is a bug in plot_date in setting the tick formatter object.
I didn't find this in any of my test or example scripts since all
those explicitly set the formatter and hence hid the bug.  At the end
of the Axes.plot_date function in matplotlib.axes, replace

        self.xaxis.set_minor_locator(formatter)

with 
        self.xaxis.set_major_formatter(formatter)

and you'll be good to go.  Note however that there is a problem with
your script in that the length of your x and y arrays must be the
same.  After making the changes above, try

from datetime import datetime
from matplotlib.dates import EpochConverter
from matplotlib.matlab import *

times = [1084195314, 1084195375, 1084195436, 1084195497, 1084195557]
vals = [10.2, 11.1, 8.7, 12.1, 12.2]
converter = EpochConverter()
ax = subplot(111)
plot_date(times, vals, converter)
savefig('test')
show()

On Fri, 2004-06-11 at 19:22, John Hunter wrote:
>     Steve> For the last week or so I've been unable to use the GTK+
>     Steve> backend with matplotlib (and PyGTK) from CVS. Instead of
>     Steve> producing a plot it colors the whole figure black. I think
>     Steve> this may be a colormap problem.
> 
> >From your post to the pygtk list, I assume you are using PyGTK 2.3.93.
> Unfortunately I don't have a good platform to test this version on
> since my system doesn't have the required glib/gtk version and I have
> learned from past experience not to try and upgrade these libs.
> 0.54.2 with the GTK backend runs fine with pygtk-2.2 on my system.
> 
> A couple of questions
> 
>  * can you run matplotlib-0.54.1 on your current version of pygtk.
>    This will help me figure out if something in matplotlib has changed
>    or if something on your system has changed.  The GTK backend is
>    fairly stable at this point so not a lot has changed.
> 
>  * Can you run matplotlib-0.54.2 with pygtk2.2 on your system?
> 
> If there is a 2.3.93 specific problem, we'll need to get it worked
> out, but I'd like to narrow the field of candidate problems first.
> 
> JDH

I've just ran lots of tests:

Matplotlib	PyGTK        GTK+ backend
----------      -----        ------------
0.54.1          2.2.0        working
0.54.2          2.2.0        working
cvs             2.2.0        working

0.54.1          cvs(2.3.93)  fails (the figure is all black)
0.54.2          cvs(2.3.93)  fails
cvs             cvs(2.3.93)  fails

It must be a PyGTK bug. 

Strangely enough I opened a PyGTK bug report today (#144135), which
turns out to be serious bug - a 'stopper' for PyGTK 2.4. It may also be
causing this problem with matplotlib. Hopefully it will be fixed soon
and if it doesn't fix this problem running matplotlib I'll open another
PyGTK bug report.

Steve

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> I ran your memory test script on my Fedora 2 PC, it gave
    Steve> Average memory consumed per loop: 168.3600 on the previous
    Steve> matplotlib Average memory consumed per loop: 41.7200 on the
    Steve> latest matplotlib from CVS.  That's a big improvement.

Well that's interesting.  I just reran the script myself because I was
getting approx 12 per loop and you are getting 40.  But now when I
rerun it I get numbers compatible with yours.  Annoying.  Back to the
drawing board.

    Steve> For the last week or so I've been unable to use the GTK+
    Steve> backend with matplotlib (and PyGTK) from CVS. Instead of
    Steve> producing a plot it colors the whole figure black. I think
    Steve> this may be a colormap problem.

From your post to the pygtk list, I assume you are using PyGTK 2.3.93.
Unfortunately I don't have a good platform to test this version on
since my system doesn't have the required glib/gtk version and I have
learned from past experience not to try and upgrade these libs.
0.54.2 with the GTK backend runs fine with pygtk-2.2 on my system.

A couple of questions

 * can you run matplotlib-0.54.1 on your current version of pygtk.
   This will help me figure out if something in matplotlib has changed
   or if something on your system has changed.  The GTK backend is
   fairly stable at this point so not a lot has changed.

 * Can you run matplotlib-0.54.2 with pygtk2.2 on your system?

If there is a 2.3.93 specific problem, we'll need to get it worked
out, but I'd like to narrow the field of candidate problems first.

JDH

On Thu, 2004-06-10 at 05:52, John Hunter wrote:
> Hi Eric,
> 
> You can test the new release which includes both Steve's changes and a
> number of fixes on my end.  I'll attach the script below that I used
> to profile the leak, a modified version of your script.  By my
> numbers, the average memory consumed per loop is down from 145.9 using
> 0.54.1 to 12.3 using 0.54.2.  Not perfect, but more than 10x better.
> 
> I have definitely identified a leak in freetype (as mentioned above,
> which is fixed in freetype CVS) and there appears to be a leak in
> libpng but I have tracked down precisely where.  Neither of these are
> terribly large.  I strongly suspect that some of the remaining leak is
> my doing, so I'll continue to try and sniff these out.  The python
> code uses a lot of circular references (figures contain axes and text
> which in turn contain a reference to the figure that contains them and
> so on) which makes the task a little harder.
> 
> Let me know how it goes.
> 
> JDH
I ran your memory test script on my Fedora 2 PC, it gave
Average memory consumed per loop: 168.3600   on the previous matplotlib
Average memory consumed per loop: 41.7200    on the latest matplotlib
from CVS.
That's a big improvement.

For the last week or so I've been unable to use the GTK+ backend with
matplotlib (and PyGTK) from CVS. Instead of producing a plot it colors
the whole figure black. I think this may be a colormap problem.

Steve

John,

Compiling with numarray improved the pcolor_demo2 times by about a 
factor of 3 when selecting numarray via numerix, although it is still a 
little slower on my machine than Numeric-linkage/Numeric Python.  No big 
deal.  I am sticking with numarray. 

Eric

>The NUMERIX variable in setup.py determines which library the
>extension code is compiled against.  Whether you use numeric or
>numarray, it will work with either, but you should get much better
>performance if you match this compile flag to the library you use
>most.
>
>Let us know if this is indeed the cause of the performance hit.  Here
>are my numbers (best of three runs)
>
>  
>

Hello,

I am having a problem with plot_date. I keep getting the error:

File "E:\Python23\Lib\site-packages\matplotlib\axis.py", line 567, in
get_minor_ticks
    numticks = len(self._minorLocator())
TypeError: __call__() takes exactly 3 arguments (1 given)

I'm using Python 2.3.2, Numeric 23.1, and matplotlib 0.54.2. Here's a
short example that exhibits the problem behavior:

-----------------------------
from datetime import datetime
from matplotlib.dates import EpochConverter
from matplotlib.matlab import *

times = [1084195314, 1084195375, 1084195436, 1084195497, 1084195557]
vals = [10.2, 11.1, 8.7]
converter = EpochConverter()
ax = subplot(111)
plot_date(times, vals, converter)
show()

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

Am I missing something obvious?

Thanks.

Michael Hauser

Hi,

I am excited about the relatively new imshow and pcolor features in
matplotlib.  I am using numarray to reduce/diagnose planetary atmospheres
simulations, which consist of temperature and velocity data on gridpoints
in longitude, latitude, and pressure.

In addition to contour plots, which is on the goals list for this project,
I would like a feature added that allows me to make velocity arrows
overlaying the pcolor or imshow images, as is common in meteorology maps.
Will such a feature be available in matplotlib, and if so, how soon?
Thanks for all the great work so far!

Cheers,
Curtis



      * * * * * * * * * * * * * * * * * * * * * * * * * * * *
    *   Curtis S. Cooper, Graduate Research Assistant         *
   *    Lunar and Planetary Laboratory, University of Arizona  *
   *    http://www.lpl.arizona.edu/~curtis/		       *
   *    Kuiper Space Sciences, Rm. 318                         *
    *   1629 E. University Blvd.,                             *
     *  Tucson, AZ 85721        * * * * * * * * * * * * * * *
      * Wk: (520) 621-1471     *
       * * * * * * * * * * * *

    'It is a great gift to have a beautiful mind but an even
     greater gift to discover a beautiful heart.`

	  --Akiva Goldsman
 (The Academy Award Winning Screenwriter of 'A Beautiful Mind`)

On Thu, 2004-06-10 at 09:57, John Hunter wrote:
> >>>>> "Eric" == Eric Firing <ef...@km...> writes:
> 
>     Eric> John, For the command-line selection mechanism of numerix.py
>     Eric> to work, the following change is needed:
> 
>     Eric> if which[0] is None: ## Add this line which =
>     Eric> rcParams['numerix'], "rc"
> 
>     Eric> Otherwise, the rcParams value clobbers the command-line
>     Eric> value.
> 
> Thanks for the alert on the numerix problem.  The numerix module was
> written before matplotlibrc existed and it appears was not properly
> updated.  It may be better to simplify this and only provide 2
> choices, command line then rc file.  Does anyone need any of the other
> methods of choosing numerix?  Is there any reason to keep .numerix or

I don't think so.  It's only useful outside the context of matplotlib.

> the NUMERIX env var?

I can't think of any reason here.  What I'd use the env var for is
probably better handled by the command line option anyway.

If no one objects, I'll rip this stuff out and update the module
docstring as Eric suggested.

Todd

>>>>> "Eric" == Eric Firing <ef...@km...> writes:

    Eric> John, For the command-line selection mechanism of numerix.py
    Eric> to work, the following change is needed:

    Eric> if which[0] is None: ## Add this line which =
    Eric> rcParams['numerix'], "rc"

    Eric> Otherwise, the rcParams value clobbers the command-line
    Eric> value.

Thanks for the alert on the numerix problem.  The numerix module was
written before matplotlibrc existed and it appears was not properly
updated.  It may be better to simplify this and only provide 2
choices, command line then rc file.  Does anyone need any of the other
methods of choosing numerix?  Is there any reason to keep .numerix or
the NUMERIX env var?


    Eric> Update on pcolor_demo2.py: strange things are going on, but
    Eric> now, using profile.py, I get 2.72 seconds with Numeric and
    Eric> 9.49 seconds with numarray.  I don't have any explanation
    Eric> for why it was taking 80 seconds with numarray when I tried
    Eric> it earlier today.  It is still much slower than with
    Eric> Numeric, though, which seems odd.

pcolor_demo2 uses imshow which is written in extension code using the
numerix/numarray compatibility layer.  Todd and Perry can correct me
if I'm wrong, but I think you'll get better numarray performance if
you compile that extension with the 'NUMERIX = numarray' in setup.py.
The NUMERIX variable in setup.py determines which library the
extension code is compiled against.  Whether you use numeric or
numarray, it will work with either, but you should get much better
performance if you match this compile flag to the library you use
most.

Let us know if this is indeed the cause of the performance hit.  Here
are my numbers (best of three runs)

                     rc setting  
                 Numeric  | numarray 
      compiled | 
      --------------------------------
      Numeric  |  0.45s   | 1.13s
      numarray |  0.59s   | 0.60s

JDH

Eric Firing wrote:

> Update on pcolor_demo2.py: strange things are going on, but now, using 
> profile.py, I get 2.72 seconds with Numeric and 9.49 seconds with 
> numarray.  I don't have any explanation for why it was taking 80 seconds 
> with numarray when I tried it earlier today.  It is still much slower 
> than with Numeric, though, which seems odd.
> 
Numarray will be slower on "smaller" operations, in particular
if one is manipulating many small arrays, or looping over many
indiviual array element accesses. I haven't profiled it but
I'm guessing the difference lies in the list comprehension that
calculates the vertices which is doing many array indexings.

Perry Greenfield

John,

For the command-line selection mechanism of numerix.py to work, the 
following change is needed:

if which[0] is None:     ## Add this line
    which = rcParams['numerix'], "rc"

Otherwise, the rcParams value clobbers the command-line value.

Update on pcolor_demo2.py: strange things are going on, but now, using 
profile.py, I get 2.72 seconds with Numeric and 9.49 seconds with 
numarray.  I don't have any explanation for why it was taking 80 seconds 
with numarray when I tried it earlier today.  It is still much slower 
than with Numeric, though, which seems odd.

Eric

John,

Numerix.py behaves quite differently from what its doc string says.  
Here is a revised doc string that describes how it behaves at present,  
with => highlighting the differences:

"""numerix  imports either Numeric or numarray based on various selectors.

0.  If the value "--numarray" or "--Numeric" is specified on the
command line, then numerix imports the specified array package.

1. The value of numerix in ~/.matplotlibrc: either Numeric or numarray

=>2. The value of numerix in /usr/share/matplotlib/.matplotlibrc, as above.
(**I don't know what the Windows equivalent is.**)

=>3. The value of numerix in matplotlib/__init__.py, in the defaultParams
dictionary, which is presently "Numeric".  Only if this is changed to None
will the search continue.

4.  If the environment variable NUMERIX is defined as either "Numeric"
or as "numarray", then numerix will import from the specified array package.

5.  If the file numerix or .numerix in the HOME directory of the current
user contains a single line specifying either "Numeric" or "numarray",
then the specified array package is imported.

6. If none of the above is done, the default array package is Numeric.

7. If the Numeric is selected and the import fails,  numarray is tried.

To summarize: the commandline is examined first, the rc file seconds,
the environment third, the configuration file next, and the default
array package is Numeric.  If everything else fails, numarray is tried.

=>In a standard matplotlib installation, however, only the first two
methods--command line and the user's rc file--of specifying the array
package will be effective for the unprivileged user.

"""

Eric

John,

Thanks very much.  If you would like me to try the new snapshot, and it 
is ready soon enough, let me know what the email attachment size would 
be, if it would exceed about 100k.  There is a limit on email size going 
to the ship, but it can be relaxed if I know in advance that something 
is coming.

I have encountered surprisingly large differences between Numeric and 
numarray:
  pcolor_demo2.py takes about 3 seconds with Numeric, 80 seconds with 
numarray.
In tests of non-plotting operations, I have generally found numarray faster.

The cruise is going fine.  Weather was a bit rough off New Zealand but I 
expect it will be fairly smooth from here on.  This is a Small 
Waterplane Area Twin Hull (SWATH) ship, so it rides better than most; it 
is a little like a catamaran on stilts, with most of the buoyancy in 
fully submerged pontoons.

Eric
...

>
>When I get everything cleaned up I'll put together some before and
>after numbers from my unit tests.
>
>Hope all is well at sea!
>
>JDH
>
>  
>

>>>>> "Eric" == Eric Firing <ef...@km...> writes:

    Eric> Yes, I saw that, tried putting in explicit gc.collect()
    Eric> calls, but it didn't help.  I concluded the problem was
    Eric> different.  I also looked at the draw function in
    Eric> backend_gtk.py.  What I don't understand is how and when the
    Eric> no-longer-used gtk objects (pixmap, etc) really can and
    Eric> should be de-allocated.  Evidently they persist when the
    Eric> python reference to them goes out of scope.

    Eric> Thanks for your changes.

Hi Eric,

You can test the new release which includes both Steve's changes and a
number of fixes on my end.  I'll attach the script below that I used
to profile the leak, a modified version of your script.  By my
numbers, the average memory consumed per loop is down from 145.9 using
0.54.1 to 12.3 using 0.54.2.  Not perfect, but more than 10x better.

I have definitely identified a leak in freetype (as mentioned above,
which is fixed in freetype CVS) and there appears to be a leak in
libpng but I have tracked down precisely where.  Neither of these are
terribly large.  I strongly suspect that some of the remaining leak is
my doing, so I'll continue to try and sniff these out.  The python
code uses a lot of circular references (figures contain axes and text
which in turn contain a reference to the figure that contains them and
so on) which makes the task a little harder.

Let me know how it goes.

JDH


import os, sys, time
import matplotlib
matplotlib.use('Agg')
from matplotlib.matlab import *


def report_memory(i):
    pid = os.getpid()
    a2 = os.popen('ps -p %d -o rss,sz' % pid).readlines()
    print i, '  ', a2[1],
    return int(a2[1].split()[0])


def updatefig(i):
    ind = arange(100)
    xx = rand(len(ind), 1)
    figure(1)
    plot(ind, xx[:,0])
    savefig('dd_ef%d.png' % i, dpi = 75)
    close(1)

    return report_memory(i)


N = 100
for i in range(N):
   val = updatefig(i)
   if i==1: start = val

end = val
print 'Average memory consumed per loop: %1.4f\n' % ((end-start)/float(N))

This is the second bugfix release of the 0.54 series

Here's the CHANGELOG

 *  Rewrote ft2font using CXX as part of general memory leak fixes;
    also fixed transform memory leaks

 *  Fixed several problems with log ticks and scaling 

 *  Fixed width/height issues for images 

 *  Fixed draw_if_interactive bug for semilogx; 

 *  Fixed text clipping to clip to axes 

 *  Fixed leading newline text and multiple newline text 

 *  Fixed plot_date to return lines 

 *  Fixed plot to work with x or y having shape N,1 or 1,N 

 *  Added renderer markeredgewidth attribute of Line2D. 

 *  Fixed tick label clipping to work with navigation.

 *  Added renderer grouping commands to support groups in
    SVG/PS. 

 *  Fixed, this time I really mean it, the singleton plot
    plot([0]) scaling bug; Fixed Flavio's shape = N,1 bug 

 *  added colorbar 

 *  Made some changes to the matplotlib.colors.Colormap to
    propertly support clim 

http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474&release_id=244568

>>>>> "Eric" == Eric Firing <ef...@km...> writes:

    Eric> John, I am using pygtk2.2, built and installed from the
    Eric> tarball on top of my existing pygtk2.0, which was installed
    Eric> from rpm.

    Eric> The problem does not seem to be inevitable with pygtk
    Eric> plotting; testing I have done so far with pyStripchart 0.0.7
    Eric> (http://jstripchart.sourceforge.net), also with pygtk2.2,
    Eric> has given no indication of a leak.  It is a much more
    Eric> specialized (hence simpler) package, though.  It draws
    Eric> directly to a DrawingArea instead of using a Pixmap.

Hi Eric, I spent a good bit of time working on the memory leak
problem.  It turns out there were numerous problems in both the
transforms module and the ft2font module, which affect all backends.
I've got the former entirely cleared up, and the latter almost done.
I'm writing some unit tests to check for leaks as I go.  In the next
day or so I should have a snapshot ready for you to test.

So while there may still be a small problem with pygtk >2.0, I'm not
aware of it.  I think the major problems rest squarely on the
shoulders of yours truly.

I wrote the transforms module using CXX, which is a C++ python
extension building library that handles most of the nasty bits for
you, including reference counting.  But I was too reliant on it, and
there were some subtleties that I was neglecting involved with
managing reference counts when new pointers are allocated on the heap
and stored in other classes.  Fortunately it was a fairly easy fix and
now the transforms are not leaking any detectable memory.

The ft2font module was another matter, since I had written that by
hand.  I decided the best way to get this in tip-top shape was to also
rewrite this using CXX, rather than work out all of the intricacies of
reference counting myself.  That was a bit more work, but I'm mostly
done.  I found one very small leak in the freetype library itself, but
a little searching on the devel list shows that it is fixed in CVS >2.1.8.
But this is only a few bytes per font instance (which are cached and
reused by matplotlib) so this shouldn't present any troubles.

When I get everything cleaned up I'll put together some before and
after numbers from my unit tests.

Hope all is well at sea!

JDH

On Tue, 2004-06-08 at 21:53, John Hunter wrote:
> >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
> 
>     Steve> There does seem to be a memory problem when using Python
>     Steve> and GTK+. Have you seen the pygtk FAQ 8.4 "Is there a
>     Steve> resource leak? Why do I run out of memory using Pixbuf?"
> 
> I submitted a patch to fix a pygtk memory leak in get_image that was
> incorporated into pygtk 2.2.
> 
>   http://bugzilla.gnome.org/show_bug.cgi?id=133681
> 
> Which version are you using?  Do you still see a problem with pygtk
> 2.2 or later?
Thanks for the link. I'm using pygtk from cvs and ran a test for myself
to check that get_image() no longer leaks memory.

I think the FAQ 8.4 reports a memory inefficiency problem, not a memory
leak. It shows a loop where you quickly allocate memory and can use a
large amount of system memory before the Python garbage collector has a
chance to free the unused memory.

Steve

John,

I am using pygtk2.2, built and installed from the tarball on top of my 
existing pygtk2.0, which was installed from rpm.

The problem does not seem to be inevitable with pygtk plotting; testing 
I have done so far with pyStripchart 0.0.7 
(http://jstripchart.sourceforge.net), also with pygtk2.2, has given no 
indication of a leak.  It is a much more specialized (hence simpler) 
package, though.  It draws directly to a DrawingArea instead of using a 
Pixmap.

Eric

John Hunter wrote:

>>>>>>"Steve" == Steve Chaplin <ste...@ya...> writes:
>>>>>>            
>>>>>>
>
>    Steve> There does seem to be a memory problem when using Python
>    Steve> and GTK+. Have you seen the pygtk FAQ 8.4 "Is there a
>    Steve> resource leak? Why do I run out of memory using Pixbuf?"
>
>I submitted a patch to fix a pygtk memory leak in get_image that was
>incorporated into pygtk 2.2.
>
>  http://bugzilla.gnome.org/show_bug.cgi?id=133681
>
>Which version are you using?  Do you still see a problem with pygtk
>2.2 or later?
>
>I'll take a look at incorporating your changes, in an case.
>
>But as Kirill pointed out, there is a separate problem with Agg that I
>have to track down.
>
>JDH
>
>  
>

Steve,

>There does seem to be a memory problem when using Python and GTK+. Have
>you seen the pygtk FAQ 8.4 "Is there a resource leak? Why do I run out
>of memory using Pixbuf?"
>
>  
>

Yes, I saw that, tried putting in explicit gc.collect() calls, but it 
didn't help.  I concluded the problem was different.  I also looked at 
the draw function in backend_gtk.py.  What I don't understand is how and 
when the no-longer-used gtk objects (pixmap, etc) really can and should 
be de-allocated.  Evidently they persist when the python reference to 
them goes out of scope.

Thanks for your changes.

Eric

>>From looking at matplotlib/backends/backend_gtk.py I noticed every
>FigureCanvasGTK.draw() operation allocates memory for a new pixmap and a
>new graphics context. So looping 200 times in your first test script
>allocates memory for 200 pixmaps and 200 graphics contexts, yet the
>pixmap size has not changed and the graphics context has not changed. I
>think it would be more memory efficient to create a pixmap and continue
>using it until a larger pixmap is required. The graphics context does
>not change its default settings, so it does little, but is required for
>the GDK calls, again it looks to me like it would be better to create
>one and reuse it.
>
>Here are some changes I made to matplotlib/backends/backend_gtk.py I
>estimate saves around 10% of the memory leak.
>However I can't check that it plots correctly properly because I
>currently get a plot of a black rectangle in GTK mode (GTKAgg works OK),
>which I think was mentioned as a numarray problem with the latest
>matplotlib release.
>
>FigureCanvasGTK.__init__(self,figure):  # add the following line
>        self.pixmap_width, self.pixmap_height = -1, -1 # new
>
>  
>
FigureCanvasGTK.draw(self): # replace with this:

>    def draw(self):
>        if not self._doplot: return
>        drawable = self.window        
>        if drawable is None: return
>  
>
>        
>        width = int(self.figure.bbox.width())
>        height = int(self.figure.bbox.height())
>
>        if width > self.pixmap_width or height > self.pixmap_height:
>            self._gpixmap = gtk.gdk.Pixmap(drawable, width, height)
>            self.pixmap_width  = width
>            self.pixmap_height = height
>
>        self.figure.draw( RendererGTK(self, self._gpixmap,
>self.figure.dpi) )
>        drawable.draw_drawable(self._ggc, self._gpixmap, 0, 0, 0, 0,
>width, height)
>
>FigureCanvasGTK.realize(self, widget): # add the following line:
>        self._ggc = self.window.new_gc()
>
>Regards
>Steve
>
>
>  
>

I have a few comments which may help to improve the matplotlib functionality:

(1) When the data values are large (or small), the mantissas are rounded off 
    in the scientific notation of the x- or y-tick labels.  For example:

>>> plot([1.e9,2.e9,4.e9])

In fact, this is a generally harder problem.  In the following contrived and 
unlikely situation, it shows the similar problem:

>>> x=1.
>>> y=1.e-8
>>> plot([x,x+y,x+3*y,x+6*y])

This example has another curious problem.  The tick labels are overploted in 
some places and missing in others.


(2) Right now, hist() can only plot filled "bar charts".  It will be 
nice if it can also plot not-filled bar charts, bars without gaps in between, 
filled with color of choice, and histogram with only the top bar, without 
the vertical bars, except at the ends.

(3) For asymmetric error bars, the x(y)err's first array is for the "-" and 
the second for the "+".  Will it be more intuitive to have that reversed?

(4) When symbols are plotted (e.g. "o" or "x"), the legend shows a bunch (4) 
of them.  Will it be better to just plot one?

Thanks,

JC Hsu

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> There does seem to be a memory problem when using Python
    Steve> and GTK+. Have you seen the pygtk FAQ 8.4 "Is there a
    Steve> resource leak? Why do I run out of memory using Pixbuf?"

I submitted a patch to fix a pygtk memory leak in get_image that was
incorporated into pygtk 2.2.

  http://bugzilla.gnome.org/show_bug.cgi?id=133681

Which version are you using?  Do you still see a problem with pygtk
2.2 or later?

I'll take a look at incorporating your changes, in an case.

But as Kirill pointed out, there is a separate problem with Agg that I
have to track down.

JDH

On Mon, 2004-06-07 at 22:17, Kirill Lapshin wrote:

> TkAgg -- works fine from console, but if ran from IDLE or PythonWin it 
> creates a window border only, does not populate it with plot. If I try 
> to move the plot window whole python session crashes with generic 
> runtime error message (windows error message box with a single Ok button).

Try running with "idle -n" rather than just "idle" by changing the
properties of a copy of the idle shortcut.

TkAgg is know to work with:
python
idle -n
IPython

TkAgg is know not to work with:
SciTE
pythonw
Pythonwin
idle

Regards,
Todd Miller

There does seem to be a memory problem when using Python and GTK+. Have
you seen the pygtk FAQ 8.4 "Is there a resource leak? Why do I run out
of memory using Pixbuf?"

>From looking at matplotlib/backends/backend_gtk.py I noticed every
FigureCanvasGTK.draw() operation allocates memory for a new pixmap and a
new graphics context. So looping 200 times in your first test script
allocates memory for 200 pixmaps and 200 graphics contexts, yet the
pixmap size has not changed and the graphics context has not changed. I
think it would be more memory efficient to create a pixmap and continue
using it until a larger pixmap is required. The graphics context does
not change its default settings, so it does little, but is required for
the GDK calls, again it looks to me like it would be better to create
one and reuse it.

Here are some changes I made to matplotlib/backends/backend_gtk.py I
estimate saves around 10% of the memory leak.
However I can't check that it plots correctly properly because I
currently get a plot of a black rectangle in GTK mode (GTKAgg works OK),
which I think was mentioned as a numarray problem with the latest
matplotlib release.

FigureCanvasGTK.__init__(self,figure):  # add the following line
        self.pixmap_width, self.pixmap_height = -1, -1 # new

FigureCanvasGTK.draw(self):  # replace with this:
    def draw(self):
        if not self._doplot: return
        drawable = self.window        
        if drawable is None: return
        
        width = int(self.figure.bbox.width())
        height = int(self.figure.bbox.height())

        if width > self.pixmap_width or height > self.pixmap_height:
            self._gpixmap = gtk.gdk.Pixmap(drawable, width, height)
            self.pixmap_width  = width
            self.pixmap_height = height

        self.figure.draw( RendererGTK(self, self._gpixmap,
self.figure.dpi) )
        drawable.draw_drawable(self._ggc, self._gpixmap, 0, 0, 0, 0,
width, height)

FigureCanvasGTK.realize(self, widget): # add the following line:
        self._ggc = self.window.new_gc()

Regards
Steve

Barry Drake wrote:

>I've recently returned to Matplotlib and Scipy (and
>happy to be back!!!).  I had the same problem and
>solved it by putting the lines
>
>import matplotlib
>matplotlib.use('WXAgg')
>
>before the usual import
>
>from matplotlib.matlab import *
>  
>

Barry, thanks a lot for your input, however I did try WXAgg, as well as 
WX and TkAgg and none of them works for me. One thing I forgot to 
mention in my previous e-mail though. I am using interactive mode. I 
just tried the same experiment in non-interactive mode, and WX works 
fine. However we are mostly interested in interactive mode, because we 
mostly use plotting for debugging purposes.

--Kirill