[SciPy-dev] plt zooming is a memory hog
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
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:
> | def draw(self,dc):
> | sz =
> | sz = sz * abs(self.scale)
> | sz = sz.astype(Int)
> | scaled_image = self.the_image.Scale(abs(sz), abs(sz))
> | bitmap = wxBitmap(scaled_image)
> | dc.DrawBitmap(bitmap, self.origin+1,
> | self.origin-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
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...
> 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
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.
More information about the Scipy-dev