Those marching ants do chew up CPU power at the default speed. I have
them set at 1000, which means one update per second. Setting them to
1000, 5000, or doesn't make any perceptible difference in the
total CPU usage. Just now I tried setting the default speed to "0",
but it reset to 10.
--
All you have to do is set marching ants speed to 10 and watch it ramp up
the CPU.
Perhaps setting marching ants speed to 0 should simply disable the updates
altogether? Generate the ants at one time, and don't bother updating them
again...
On Sat, Mar 23, 2013 at 9:39 AM, Nicolas Robidoux <
nicol
Chiming in:
Multi-core requires "love" to work well.
ImageMagick, for example, has been known to run considerably faster on busy
systems with openMP disabled.
In GIMP 2.6, frequent "marching ants" were a CPU sink. (Bad "observer
effect".)
___
gimp-devel
On Fri, 2013-03-22 at 16:34 -0400, Elle Stone wrote:
> I'd prefer that Gimp to monopolize both CPUs and get the job done
> twice as fast. Would a real-time kernel setup like the audio linux
> distributions use help? Is there a setting in Gimp that I missed? Or a
> compile-time switch in babl, gegl
More RAM does help quite a bit. With 12GB RAM instead of just 4GB. +
using the optimized babl/gegl/Gimp installation. + starting Gimp with
"GEGL_SWAP=RAM", painting with a brush is no longer quite the painful
chore that it was.
The main sticking point now is redrawing the canvas (correct
terminolo
On 03/02/2013 10:15 PM, Nicolas Robidoux wrote:
> Indeed, maybe -g does not affect performance. I did not measure.
>
> http://stackoverflow.com/questions/89603/how-does-the-debugging-option-g-change-the-binary-executable
>
Thanks for the link, interesting (and slightly unnerving) to read that
the
Indeed, maybe -g does not affect performance. I did not measure.
http://stackoverflow.com/questions/89603/how-does-the-debugging-option-g-change-the-binary-executable
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.o
On 03/02/2013 03:55 PM, Nicolas Robidoux wrote:
> If anybody wonders why -march=native is not used by these libraries by
> default, it's because it makes the binaries non-portable.
>
> Also, the default build uses -g, which turns on debugging, for obvious
> reasons, but which of course gets in the
Well, you have a point. But if you look at the documentation, it says:
-OfastDisregard strict standards compliance. -Ofast enables all -O3
optimizations.
It also enables optimizations that are not valid for all standard-compliant
programs. It turns on -ffast-math and the Fortran-specific
-fno-prot
On 3/2/13, Partha Bagchi wrote:
> I thought Gentoo was all about optimizing a linux distribution to your
> specific proecessor. :)
>
> Anyway, try the following optimization and see if it makes a difference in
> your setup:
>
> ./autogen CFLAGS="-O3 -ffast-math -ftree-vectorize" ...
Sorry! I spok
Elle:
Factor of two in some cases. Not bad for two simple flags (-march=native
-Ofast).
-
If anybody wonders why -march=native is not used by these libraries by
default, it's because it makes the binaries non-portable.
Also, the default build uses -g, which turns on debugging, for obvious
r
I thought Gentoo was all about optimizing a linux distribution to your
specific proecessor. :)
Anyway, try the following optimization and see if it makes a difference in
your setup:
./autogen CFLAGS="-O3 -ffast-math -ftree-vectorize" ...
On Sat, Mar 2, 2013 at 8:49 AM, Elle Stone wrote:
> B
Being curious about optimization, I set up two identical installations
of babl, gegl, and Gimp, in separate, side-by-side prefixes (same
partition, hard drive):
In "gimp291" babl, gegl, and Gimp were compiled with ./autogen.sh . . .
In "gimp292" babl, gegl, and Gimp were compiled with
CFLAGS="-m
>
> 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?
>
~/.cache/gegl-0.2/
Yes it will limit you to available ram for the image buffers; but if you're
in a circumstance where you would actuall
On 2/28/13, Liam R E Quin wrote:
> Quark Express used to have the notion of a "project folder", and if you
> put fonts in it, they'd be activated only when working on the files in
> that folder. I miss this, but gimp is scatterbrained when it comes to
> folders, with export going to the last place
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.gimpu
On Thu, 2013-02-28 at 14:51 -0500, Elle Stone wrote:
> On 2/28/13, Liam R E Quin wrote:
> I switched to the nonfree nvidia distributed by openSUSE because the
> nonfree driver manages the fan better. Do you think the openSUSE
> version might be properly patched?
Yes, that's fine, just avoid down
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
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=RA
On 2/28/13, Liam R E Quin wrote:
> In the meantime,
> (1) look at what other processes are running - e.g. in "top" you can
> press M (not m) to sort processes by size, and the results can sometimes
> be surprising...
Thanks very much! for the tip on how to sort in top.
> (2) in gimp...
> even w
There is a little bit of c++ floating around here and there TTBOMK.
-
Make sure to wear safety goggles and a flak jacket.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
On 2/28/13, Nicolas Robidoux wrote:
> Warning: Untested
>
> If you build/compile GIMP and key libraries (e.g. GEGL, BABL) from source,
> maybe you should try
>
> CFLAGS="-march=native -O3" CXXFLAGS="-march=native -O3" ./autogen.sh ...
CFLAGS is for c code CXXFLAGS is for c++ code, according to in
On Thu, 2013-02-28 at 12:16 -0500, Elle Stone wrote:
> Short of building a new computer (not going to happen!), what else can
> I do to improve Gimp performance? Which hardware upgrade(s) might give
> the most performance improvement for the least amount of money?
More memory. Max it out.
In the
Warning: Untested
If you build/compile GIMP and key libraries (e.g. GEGL, BABL) from source,
maybe you should try
CFLAGS="-march=native -O3" CXXFLAGS="-march=native -O3" ./autogen.sh ...
instead of the usual
./autogen.sh ...
This may, or may not, make a noticeable difference.
But if I was con
When working with full-size camera files (3906 X 2602 px, not large
compared to more recent cameras), Gimp runs at 100% CPU. Painting a
brush stroke takes forever, my system swap drives fill up completely,
etc. And yesterday Gimp filled up 15GB's worth of empty space in my
home directory, leaving m
24 matches
Mail list logo
