I am concerned a little about memory usage and caching. In image.c, images
are run through an image optimizer for OS3.5+. This means that a copy of
the image is created by BmpCreate, on the heap I assume. A pointer to
this copy is then added to the cache. The item is then deleted from the
heap when ResetCache() is called, which happens according to the comments
when a new document is loaded.
What this means is that as one loads more and more images in during a
session, they start filling up RAM. Eventually, presumably, so much RAM
will be used up that the optimizer will fail. That's not of itself a big
problem--there just won't be any optimizing going on. However, my worry
is that if we reach that point, RAM will be very scarce all around. And a
scarcity of RAM can create trouble for other parts of the viewer, e.g.:
1. Showing images on OS5 which requires the allocation of an extra bitmap
buffer in hires.c/ConvertImageToV3().
2. Rotation which generally allocates memory for bitmaps.
3. And a whole ton of stuff that allocates memory for miscellaneous
purposes.
It does not seem to me to be a good thing to keep on filling up memory
with bitmaps until there is no memory left.
There is another problem in the image caching code, which does not
actually ever occur, but... Well, you'll see in a moment. The
optimization code allocates a new bitmap. This bitmap is added to the
cache. The only place this bitmap is deallocated is when the cache is
cleared. This means that if the cache is disabled, the bitmap is never
added to the cache and hence never deallocated. Fortunately, as the code
stands now, the cache is always active, except for OS ver < 3.1. And by a
helpful coincidence, the optimization code is only invoked for OS ver >=
3.5. So it all works. But it's messy, and could easily break if some
programmer doesn't understand it later on. It would be all to easy for
someone to supply an image optimizer for OS ver < 3.5, thinking that it
can just be plugged right in like the 3.5+ optimizer. And it would be all
too easy for someone to try to make the Prefs() caching option actually DO
something, which would again make it possible for the cache to be disabled
while the optimizer is working, with a horrible memory leak resulting.
There is an easy fix here: only call the optimizer if the cache is
enabled. But before I implement this, I need to ask: Does the optimizer
do anything useful if the cache is not enabled? (Well, it does do one
thing: It reduces memory usage for rotated viewing of bitmaps with higher
depth than the current screen.)
Alex
--
Dr. Alexander R. Pruss || e-mail: [EMAIL PROTECTED]
Philosophy Department || online papers and home page:
Georgetown University || www.georgetown.edu/faculty/ap85
Washington, DC 20057 ||
U.S.A. ||
-----------------------------------------------------------------------------
"Philosophiam discimus non ut tantum sciamus, sed ut boni efficiamur."
- Paul of Worczyn (1424)
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
