[Gimp-developer] memory usage [was: comparing gimp speed]

[Sven Neumann]

Hi,

there are probably a few things we could try to do to reduce memory
usage when working with large images. The main problem here is that if
you open an RGB image (no alpha channel) with say 1000 x 1000 pixels,
you would expect GIMP to use 1000 * 1000 * 3 bytes to store the image
data. You will however notice that GIMP instead needs 8 bytes per
pixel. In addition to the 3 bpp for the RGB layer it allocates a
projection the size of the image. This projection holds the result of
compositing the layer stack. It is always allocated 4 bpp. Additionally
a selection mask is allocated which adds another byte per pixel.

So what could be done to improve this? We could for example try to get
around the need for a projection for the case where people are working
with a single layer only. Instead of displaying from the projection,
we could display directly from the layer. Of course we would still
have to allocate the projection as soon as you start to work with
layers or floating selections but at least we could reduce the memory
footprint that is needed to open the image and have a first look at it.
A more elegant way to implement this is is to share the projection
tiles with layer tiles whenever possible (i.e. when the topmost layer
is in Normal mode and the tile is completely opaque).

It might also help to allocate the selection lazily. That is to not
allocate the tiles at all until the selection mask is altered. This
might actually happen already, I am not sure about it.


Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] memory usage [was: comparing gimp speed]

[Adam D. Moss]

Sven Neumann wrote:
 You will however notice that GIMP instead needs 8 bytes per
pixel. In addition to the 3 bpp for the RGB layer it allocates a
projection the size of the image. This projection holds the result of
compositing the layer stack. It is always allocated 4 bpp. Additionally
a selection mask is allocated which adds another byte per pixel.
(As an aside, once upon a time, we did have such a thing as
greyscale projections.)
So what could be done to improve this? We could for example try to get
around the need for a projection for the case where people are working
with a single layer only. Instead of displaying from the projection,
we could display directly from the layer.
I think we used to do this, too.  At least, I struggled for a
long time making the projection tiles be initialised to a lazy
copy-on-write reference to the bottom layer (IIRC the tile hinting
system would also preserve these cheap refs even when there
were multiple layers where the upper layers were largely
transparent).  There were some annoying corner cases (duplicating
a zoomed-in image) which I now don't remember if we ever got
right. :(
But it still seems like the elegant way to do this (erk, but it
probably did rely on the projection being able to assume the
same depth as the image).
It might also help to allocate the selection lazily. That is to not
allocate the tiles at all until the selection mask is altered. This
might actually happen already, I am not sure about it.
Not sure.  Might be able to do this elegantly (elegance again being
in the eye of the beholder) by initialising all of the selection
tiles to a COW of the same 'blank' tile (and doing the same in
the 'clear selection' operation, etc).
--Adam
--
Adam D. Moss   . ,,^^   [EMAIL PROTECTED]   http://www.foxbox.org/   co:3
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer