Re: [Gimp-developer] Re: Re: optional scaling in the save dialog?

[Joao S. O. Bueno Calligaris]

That is great.

I did not know that the GIMP could reuse tiles from one image to 
another. Actually, I didi not tought this was done even from a layer 
to another - that explains why adding new layers to large images goes 
so smoothly.

I am more than happy.

How does this memory usega behave when one apply a transform (scale 
down in this case), ont he image, or on a copy of it?

Because Mateusz wrote me that the disabling undo improved the 
performance of the operation. 

Maybe it is just the beneffits f not having  "X" allocated anymore, 
and therefore no more swaps after the scale down.

Regards,

JS
-><-


On Sunday 20 February 2005 11:43, GSR - FR wrote:

> I assume there is Copy On Write, thus delaying real memory usage
> (and the bandwidth too) until the data changes. Lets see COW at
> work:
>(...)
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] Re: Re: optional scaling in the save dialog?

[GSR - FR]

Hi,
[EMAIL PROTECTED] (2005-02-20 at 0203.45 -0200):
> Let X bre a Huge Amount of Memory (tm) taken by said image, and Y be A 
> Couple Kilobytes (tm) used by scaled down version
> Your proccess: 
> - Initially using X memory
> duplicate image -> now using x * 2 memory.

I assume there is Copy On Write, thus delaying real memory usage (and
the bandwidth too) until the data changes. Lets see COW at work:

Just after launching gimp:

 total   used   free sharedbuffers cached
Mem:514308 04  69904  0   6180 137996
-/+ buffers/cache: 300228 214080
Swap:   264144  63140 201004

2000*2000 image created and plasma filter run:

 total   used   free sharedbuffers cached
Mem:514308 500864  13444  0   6336 138012
-/+ buffers/cache: 356516 157792
Swap:   264144  63140 201004

script-fu console launched:

 total   used   free sharedbuffers cached
Mem:514308 503428  10880  0   6372 138268
-/+ buffers/cache: 358788 155520
Swap:   264144  63140 201004

gimp-image-duplicate invoked once, id reported is 2:

 total   used   free sharedbuffers cached
Mem:514308 503000  11308  0   6532 138260
-/+ buffers/cache: 358208 156100
Swap:   264144  63140 201004

Invoked 3 more times (ids 3, 4 and 5), to check the apps is not
reusing memory it already owns:

 total   used   free sharedbuffers cached
Mem:514308 503008  11300  0   6568 138260
-/+ buffers/cache: 358180 156128
Swap:   264144  63140 201004

OK, pushing the limits, so invoked 46 times more (ids 6 to 51):

 total   used   free sharedbuffers cached
Mem:514308 504308  1  0   7284 136336
-/+ buffers/cache: 360688 153620
Swap:   264144  63364 200780

Used swap and mem (after removing buffers and cache) numbers seem
pretty stable, just mimimal increases in both, some KB reduction
sometimes (other app releasing mem probably). By your rule, the
machine should be crawling now due the 50 copies. Just the pixels are
50 * 2000 * 2000 * 3 = 600 * 10^6, more than the physical RAM.

  (__)
  (oo) Moo Super Powers
   /---\/
  / | ||
 *  ||||
~~~~

GSR
 
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer