Re: [Gimp-developer] gimp 2.8 prohibitively slow

[SorinN <nemes sorin gmail com>]

> One thing I noticed is that actually loading the images is very expensive,
> and gimp doesn't behave very well while it's happening. It took several
> minutes to load the large image, and while it was doing it, X was mostly
> unresponsive. Is there room for improvement here?

Same effect under WIndows 7 with GIMP 2.8 and GIMP 2.8.1 - Partha compilation
but I think developers are already aware about that - probably is a
normal fact in the
middle of transition new GEGL core. Side effects are expected. Beside the
problem with large images in 2.8.x - also you will find some crashes related to
memory allocation when you will use GEGL for rendering the canvas and colors or
when you will use GEGL Operations.

If you use compilations from trunk - versions bigger than 2.8 (mean
2.8.1) - you will also
observe some GEGL operation get serious speed on execution, especially blur
operations - on Windows 7 and GIMP 2.8.1 from partha.com, gaussian
blur perform very fast now
even on mid-to-large images. The UI controls are not responsive but I
use input fields and results are
rendered instantly.

2012/7/19 Aaron Paden <aaronbpaden gmail com>:
> Hello, Liam. I've tried your suggestions and have gotten some pretty good
> results. My large image used for this test is still not practically
> editable, but I was having problems even with relatively small images in
> gimp, and these workarounds have really improved gimps responsiveness and
> usefulness for me. The brush can now (mostly) keep up with my hand! :)
> Thanks for your insight.
>
> One thing I noticed is that actually loading the images is very expensive,
> and gimp doesn't behave very well while it's happening. It took several
> minutes to load the large image, and while it was doing it, X was mostly
> unresponsive. Is there room for improvement here?
>
>
> On 07/18/2012 11:01 AM, Liam R E Quin wrote:
>>
>> Try increasing the tile size in your gimp preferences e.g. to two
>> gigabytes (and make sure you have at least three gigabytes of swap
>> space).
>>
>> To work with this image in gimp on a 32-bit system you will need:
>>
>> (1) to have as large a tile cache size as you can -that's the amount of
>> memory gimp devotes to keepng the image in memory instead of on disk
>>
>> (2) have the Undo History window in your dock, and use the button at the
>> bottom right to Discard Undo History roughly every 30 to 50 brush
>> strokes. Unfortunately I don't think you can bind that to a keyboard
>> shortcut, so you need the undo history window docked.
>>
>> (3) save work frequently as xcf.gz - do not overwrite the same file each
>> time, in case you run out of memory while gimp is saving the file. Save
>> and Expert go much faster if you discard the undo history first.
>>
>> (4) turn off thumbnails everywhere you can,
>> e.g.,
>> in edit/preferences/interface,
>>    turn off Enable Layer & Channel Perviews
>> in edit/preferences/Toolbox,
>> . turn off the "show active image"
>> in edit/preferences/Image Windows, you may want to
>> . turn off Show brush outline
>> this may make painting faster but unuseable, though.
>> . set pointer mode to rendering to crosshair only
>> . set pointer rendering to black and white
>>
>> (5) make sure your gimp title bar shows the amount of memory in use - if
>> it doesn't, go to Edit/Preferences under Image Windows, Title and
>> Status; for Image Title format I have
>>
>> %D*%f-%p.%i (%t, %L) %wx%h %m
>> (the default except for adding %m for memory)
>> and for Image status bar I have
>> %n (%m)
>> (the default)
>> That way if the status bar is saying something else, e.g. while you're
>> painting, you can still track memory usage easily.
>>
>> (6) in edit/preferences/colour management,
>> . set Mode of operation to No color management
>>    (I just notice "colour" is misspelt there)
>>
>> (7) do not use a theme with transparency. In Windows, use the classic
>> windows theme. In Linux, do not use compiz or a compositing window
>> manger (the ones that put drop shadows under windows), because these to
>> tend to reduce (sometimes halve) painting speed and increase memory
>> usage.
>>
>> Hope this helps.
>>
>> Liam
>>
>
> _______________________________________________
> gimp-developer-list mailing list
> gimp-developer-list gnome org
> https://mail.gnome.org/mailman/listinfo/gimp-developer-list



-- 
Nemes Ioan Sorin