I followed Nicolas' suggestion and recompiled babl, gegl and gimp with CFLAGS="-march=native -O3" CXXFLAGS="-march=native -O3". The computer didn't blow up or anything. But I can't say whether Gimp runs any faster. The idea of optimization seemed promising and I found this thread: http://www.gimpusers.com/forums/gimp-user/14320-benchmarking-gimp-gegl#message66197 Does optimization depend on the actual processor? Is there a set of optimizations that makes sense for a circa 2005 AMD Opteron 252 (soon to be 262) processor? It has built-in floating point etc, was considered very fast when doing mathematical operations (that's why I picked it). What about these: -Ofast -ffast-math -ftree-vectorize ? Others? Is there any danger to the computer when recompiling packages using these flags? Or just the danger of the occasional math error? What about cairo, gtk, etc? Would it make sense to compile these from source using optimizations of some sort or another? Or are they already compiled with all sensible optimizations by openSUSE? On 2/28/13, Daniel Sabo <danielsabo@xxxxxxxxx> wrote: > You might want to try running gimp with GEGL's swap turned off, this will > avoid filling up your drive with cache files: > GEGL_SWAP=RAM gimp-2.9 Does this mean Gimp and gegl would be competing for my meagre 4gb of ram? I didn't know gegl wrote cache files. Where does gegl write its cache files? > If you don't have OpenCL set up forcing it off will give a bit of a > performance boost (due to a bug in the detection code): > GEGL_USE_OPENCL=no GEGL_SWAP=RAM gimp-2.9 How does one set up OpenCL? Is it just a matter of having the right graphics card and driver? I will try both ways, with and without opencl, and with nvidia driver and nouveau driver (both have OpenCL support, it seems) and see if there seems to be a difference. Is there a way to tell Gimp to use or not use OpenCL? Or a way to tell if it really is being used? > Painting speed is due to bugs in GEGL and Gimp's paint core, there's really > nothing you can do right now to get it speedy. Ah, well, someday... Other things are also slow. Just hiding/unhiding a layer is slow, until the image is resized down. 768x512 is reasonably fast, though the brush is still slower than I'd like it to be (but useable). When compiling Gimp, would any of the following compile options speed things up while using Gimp? --without-libexif --without-aa --without-libxpm --without-libmng --without-wmf --without-webkit --without-librsvg --without-poppler --without-print --without-gvfs --without-alsa --without-mac-twain --disable-gtk-doc --without-script-fu --disable-python --without-dbus --without-linux-input --without-hal And while I'm asking questions, what is the "Linux Input Controller module"? Does it have anything to do with tablet support (I use a tablet)? Sorry to be asking so many questions! I've been using Gimp a lot in the last couple of weeks and liking it more and more and more, except for the speed of execution. So I'm trying to figure out what the options are for improving performance. Elle -- http://ninedegreesbelow.com - articles on open source digital photography _______________________________________________ gimp-developer-list mailing list gimp-developer-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gimp-developer-list
