Re: [Gimp-developer] gimp 2.8 prohibitively slow
On 07/19/2012 02:28 AM, wwp wrote: even though when attempting to process image/data files that are, say, modern. The OP didn't mention precisely how big they are (trying to open large images like MyPaint encourages), but I presume they are way bigger than image sizes that were conventional in the times P4 + 512Go RAM were common. How big are they, Aaron? MyPaint encourages large images because of the infinite canvas. It adds up pretty quickly. The largest one I was using to test gimp was 8960x9088. Just some doodles. More me testing the limits of gimp on my computer than trying to do something useful in that case. Gimp was unusably slow no matter what size image I use, but Liam's suggestions have made things much more manageable. https://mail.gnome.org/archives/gimp-developer-list/2012-July/msg00074.html ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] gimp 2.8 prohibitively slow
So I mostly use MyPaint, but I'd like to be able to do some things in gimp, too. But gimp is way too slow on this computer. Especially trying to open large images like MyPaint encourages, I'll have to run to another tty to try and kill the process so I can continue to use my computer. I've got an old Pentium 4 with only about half a gig of RAM. A bit behind the times, but especially on Linux it's generally fast enough to get the job done. Is there anything I can do to help improve performance? I don't have much experience. I doubt I could write anything any faster. But maybe I can do something to help identify bottlenecks? Anything I can do to help, I'm game. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp 2.8 prohibitively slow
It's definitely on the low end, but I'm positive that gimp can do better! Of all the graphics programs I've tried on this computer, gimp 2.8 performs the worst. Even krita is a little better, which I thought was surprising. It's able to at least load my largest image (8960x9088, 7 MB) after awhile without halting and crippling my DE, though it takes about 6 seconds to register from pen to paper. I'm not quite sure how the MyPaint guys do it. I think it might involve virgin sacrifice. On 07/18/2012 09:55 AM, Guillermo Espertino (Gez) wrote: On 18/07/12 10:45, Aaron Paden wrote: So I mostly use MyPaint, but I'd like to be able to do some things in gimp, too. But gimp is way too slow on this computer. Especially trying to open large images like MyPaint encourages, I'll have to run to another tty to try and kill the process so I can continue to use my computer. I've got an old Pentium 4 with only about half a gig of RAM. A bit behind the times, but especially on Linux it's generally fast enough to get the job done. Is there anything I can do to help improve performance? I don't have much experience. I doubt I could write anything any faster. But maybe I can do something to help identify bottlenecks? Anything I can do to help, I'm game. You can try turning off color management in your preferences (there's a bug in GIMP 2.8 that makes painting tools and selection widgets slower when color management is active) and you can try with different tile memory settings but I'm afraid your system specs are low for high resolution painting in a program like GIMP. hth, Gez. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp 2.8 prohibitively slow
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
