[SciPy-dev] plt zooming is a memory hog

eric eric at scipy.org
Mon Nov 12 08:43:20 CST 2001

> Ok, I looked at the problems reported by Eric regarding zooming into
> images, leading to crashes regularly.
> (here: Linux 2.4, wxPython 2.3.1, 128MB RAM, 512MB swap)
> I could not reproduce any lockups or crashes (as reported by
> Eric).

I think your seeing the same thing.  Memory going to 600 MB on my machcine
would cause lockup.

> The image is always drawn fine after *some* time, unless I
> killed the app because I am tired of waiting after a few minutes!

> The reason why it took so long? Making the shown part of the image
> small enough (the number of "zooms" doesn't matter, just the size of
> the selected part), the python process and the Xserver grow to >600 MB
> together... (v.s.)
> Well the problem is here:
> ,----[plot_objects.py:956--963]
> |     def draw(self,dc):
> |         sz =
> |         sz = sz * abs(self.scale)
> |         sz = sz.astype(Int)
> |         scaled_image = self.the_image.Scale(abs(sz[0]), abs(sz[1]))
> |         bitmap = wxBitmap(scaled_image)
> |         dc.DrawBitmap(bitmap, self.origin[0]+1,
> |                       self.origin[1]-scaled_image.GetHeight()+1,
> `----
> A wxImage and a wxBitmap of the whole image at the needed resolution
> is made. These are huge bitmaps if you zoom in a bit, I assume:((

Looks like we'll have to write our own replacement for the Scale()
that does things more intelligently.  I guess the wx stuff wasn't designed
for this
sort of thing.

> I have no good quick way on how to handle this, but somehow this
> image_object needs to know which part of itself we are interested in
> and only draw that...
> Greetings,
> Jochen
> PS: Since changes are still not in cvs and I couldn't find all patches
> flying around, I attach the version of plt I used. This is a diff
> against current cvs.
> PPS: Eric, what's about Linus rule "release early, release often"?
> It's up to you guys, but I would suggest you release snapshots as
> often as you encounter an overall reasonably stable source tree, and
> put changes in cvs as soon as they are there?
> Or something like
> that. At least I am tired of sending patches between different
> machines I am using. I have actually considered setting up my own
> (private) cvs tree for scipy, but that is not really what I want.

It'd be good to have a nightly snapshot set up.  The hope is to have
something akin to VTK's setup (http://public.kitware.com/VTK/)
where they have a "quality dashboard" of how the unit tests ran on
the latest CVS snapshot and a build of multiple daily versions for
multiple platforms.

I haven't worked on this at all, and won't in the near future.  There is
certainly room between the current setup and the "grand vision" for
a less ambitious but automated build process.  If someone wants
to volunteer for setting it up (or even the grand vision), that be great.

see ya,

More information about the Scipy-dev mailing list