On Thu, 20 Jul 2000 21:45:05 -0000, "somnorici " <[EMAIL PROTECTED]> said:
>I set the undo levels to zero and loaded an image. 9376 by 11488
>pixels grayscale is 107,711,488 bytes. My display depth is 16
>bits. It didn't take long to link this with the swap file, which
>after loading the image was 292,421,632 bytes, plus the 32 megs of
>tile cache (it's on a 64 megs machine used for testing), it kinda
>equals three times the size of the image.
Yes, because there's a selection mask of equal size to the image, and
a projection buffer, also of equal size to the image. Although I
think that if there's no selection mask, that tilemanager should be
unallocated, and when there's only one layer, the background layer
doubles as the projection buffer, so there shouldn't be a separate
projection buffer. It's been quite a while since I dug around in this
part of the code, though.
>This takes me to the conclusion that gimp kindly allocates the memory
>for storing the image after extracting it from the file, and the
>whole image used for displaying, instead of only 3-7% which is
>actually used for an image so big. Now this is a serious thing, and
>I'll have to start digging the source to fix it... Is there anyone
>else aware/working on this issue?
Well, it has to allocate the memory to store the image somewhere, even
for parts that aren't presently being viewed. It's not practical to
swap image data from the source file; most image storage formats are
compressed such that it is not possible to read data out of the file
except sequentially from the start.
Kelly
