DzZero <[EMAIL PROTECTED]> writes:
> I am not sure if it is related at all but GIMP (as much as I hate to
> admit it) has some severe memory issues with large files. Or
> something gimp uses really I dont know.
if you have such problems, you should report them using Bugzilla
> I regularly deal with 400-800MB images and gimp just chokes on the
> big ones. 400-500 I can normally work with for a period of time but
> it will ultimately choke. And yes we have the hardware to back it
> up. 1.5-2GB of ram and 1GB of swap and using at most 1 undo
> level. These are normally greyscale (8bit images). On occasion the
> larger files (800MB range) are color. I have also tweaked the tile
> cache size in all forms. Sometimes setting it big works sometimes
> small. Seems to be no ryme or reason as to why.
could you have a look at the size of the swap file when this happens?
If it has grown to about 2GB, you are seeing bug #74478.
> I have noticed issues related to clipping as well. Under this
> situation using a small tile cache seems to work most of the time. I
> can have the same memory available. Open a 100MB image. Import a
> path. Clip to the path using copy and repaste that into a new
> image. At that point I can not save. If I attempt to GIMP again
please report to Bugzilla.
> I would submit an strace of this but the fact is if I do so the
> strace alone is going to be MBs of info. Does anyone really want to
> rumage through it?
straces are rarely useful to debug an application like The GIMP. I
suspect that when you say 'choke', you are talking about a
segmentation fault. It would be useful to get a stack trace from such
a crash. Please don't confuse strace with stack trace, these are two
different things. You can get a stack-trace from GIMP by using the
command-line option '--enable-stack-trace alyway'. I doubt however
that this will work on Windows due to the lack of gdb.
Gimp-developer mailing list