[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!

yep.
>
> 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 =
array((self.the_image.GetWidth(),self.the_image.GetHeight()))
> |         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,
wx.false)
> `----
> 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()
functionality
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,
eric






More information about the Scipy-dev mailing list