[Gimp-developer] [OT] Thanks for Gimp!
So, I've been thinking about all of the apps I use on a daily basis, and decided I should go out and send 'thank you's to the developers. :^) So, thanks, everyone, for The Gimp! My wife and I use it at home, and I use it at work. :^) -- -bill! [EMAIL PROTECTED] I'm anticipating an all-out tactical http://newbreedsoftware.com/ dog-fight, followed by a light dinner. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] newbie: how to scan lines?
hi all, I am a newbie. Q.1) I am writing a plugin which requires comparing one row of pixels with the one following it. Here is what I could think of, iterate over pixel regions (width = image width, height = tile height): iterate over rows in current pixel region: do comparison; cp the last row into buff for cmp with first row of next rgn is that advisable? how should it be done? Q.2) Could someone please point me to resources for making my plugin multithreaded? One part of the algorithm involves quantizing the image, and the other involves user input. They are independent steps. Is it advisable to use one thread to launch the quantizing step, while the other waits for user input? I am planning to give a decent, default set of parameters for quantizing, and if the user is unhappy, he should be able to change it. Any suggestions? Any help is welcome, Thanks in advance, Balachandran C.
Re: [Gimp-developer] Makefile fix for srcdir != objdir
On 27.02.2005, at 02:55, Manish Singh wrote: Only to those containing sources which refer to automatically generated headers, about 3 or 4. No, we should add it to all of them. Agreed. Consistency is good. In fact, it already *is* in some of them. So here's what I'm currently doing. I took the 4 lines block -I$(top_builddir) -I$(top_srcdir) -I$(top_builddir)/app -I$(top_srcdir)/app and put it into all app/*/Makefile.am instead of their incomplete or shuffled variants. This makes the include paths consistent across all subdirectories and hopefully take care of all problems without causing sideeffects. I'm compiling with those changes right now. ./autogen.sh on one system, make dist it, and unpack and build from your disted tarball for the rest of your builds. Cool, I've been searching for a target release or something but couldn't find it... ;) Or just do your due diligence and be consistent about all your dependencies on the targets you build on. This is impossible for various reasons. One being that auto* like to link into the filesystem which would need identical directory and installation setups on all, likely very different, systems, (e.g. Linux and OS X). Another being that different devices have different capabilities and for instance no graphical output or run Gtk+2 on a different backend like Windows or DirectFB. Which brings me to the next problem I'm facing on x86_64 Linux: the screenshot plugin fails to link because it tries to -lX11 directly which for some reason cannot be found because the library path seems to be incomplete at the point of reference... Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] Makefile fix for srcdir != objdir
On 27.02.2005, at 03:09, Manish Singh wrote: But that's still not the cure for all possible problems that may arise by moving the header (e.g. from app to libfoo). Anyway, that's better than nothing... There's no getting around updating the Makefile.am for that. With your naive solution, it *adds* a reason. Your wisdom is hard to grok at times but since we're obviously on the same page I'll go ahead and implement your solution I sought after. Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] newbie: how to scan lines?
Hi, balachandran c [EMAIL PROTECTED] writes: Q.1) I am writing a plugin which requires comparing one row of pixels with the one following it. Here is what I could think of, iterate over pixel regions (width = image width, height = tile height): iterate over rows in current pixel region: do comparison; cp the last row into buff for cmp with first row of next rgn is that advisable? how should it be done? Why don't you just iterate over the image row by row? If you set the plug-in tile cache large enough, libgimp will take care of minimizing the amount of data that is being sent over the wire. Of course you can try to optimize this further but it will most probably not be worth it unless you are working on very large images and are low on memory. Q.2) Could someone please point me to resources for making my plugin multithreaded? You can do that using gthread (part of GLib) but it is questionable if it's worth the effort. You would have to synchronize access to libgimp since libgimp isn't MT-safe. One part of the algorithm involves quantizing the image, and the other involves user input. They are independent steps. Is it advisable to use one thread to launch the quantizing step, while the other waits for user input? You could run the quanitization as an idle handler in the plug-in's main loop. You just need to split it into reasonably small chunks. That will probably be easier than a multi-threaded approach and it avoids the problems you would get with threads. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and multiple processors
On 27.02.2005, at 01:04, Sven Neumann wrote: I have eliminated last_visited from the gradient struct. Instead the caller of gimp_gradient_get_color_at() may now do the same optimization without any caching in the gradient itself. I very much doubt that this makes any difference though. Perhaps if you would benchmark a gradient blend with a lot of segments. But in the general case it's just a few of them, very often even only a single one. Now that this race condition is eliminated I might look into adding hooks to the pixel-processor to allow initialisation of per-thread data, like for example a GRand. Your change dramatically changed the picture. Instead of: Linear Gradient blend on a 3000x3000 pixel image (Dithering on) 1 processor:7.5 s 2 processors: 9.6 s 4 processors: 9.6 s Linear Gradient blend on a 3000x3000 pixel image (Dithering OFF) 1 processor:3.0 s 2 processors: 2.5 s 4 processors: 2.5 s I now get: Linear Gradient blend on a 3000x3000 pixel image (Dithering on) 1 processor:7.2 s 2 processors: 8.9 s Linear Gradient blend on a 3000x3000 pixel image (Dithering OFF) 1 processor:2.5 s 2 processors: 1.5 s However dithering on is still loosing quite a bit on this SMP machine Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] GIMP and multiple processors
Hi, Daniel Egger [EMAIL PROTECTED] writes: Your change dramatically changed the picture. That surprises me, but there is obviously a lot I have to learn about threads. Thanks for testing my changes. However dithering on is still loosing quite a bit on this SMP machine Dithering makes heavy use of GRand and as long as the random number generator is shared between the threads... I wonder if it actually makes sense to add the overhead of per-thread data initialization or if we should rather replace the use of a random number generator with a pre-calculated dither pattern. That would improve the single-threaded case as well. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and multiple processors
On 27.02.2005, at 14:31, Sven Neumann wrote: Dithering makes heavy use of GRand and as long as the random number generator is shared between the threads... I wonder if it actually makes sense to add the overhead of per-thread data initialization or if we should rather replace the use of a random number generator with a pre-calculated dither pattern. That would improve the single-threaded case as well. Since the randomness doesn't play a big role here (like in a security environment) I wonder if it wouldn't be easiest to employ a per-thread pseudo-RNG seeded with a different random number. One global RNG would be nice for this... BTW: How often is gradient_fill_single_region_rgb being called? Maybe we can simply make the RNG a local property of this and the ..._gray function and be done with it; that of course wouldn't make much sense if it ends up being called a million times per fill... Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] GIMP and multiple processors
Hi, Daniel Egger [EMAIL PROTECTED] writes: Since the randomness doesn't play a big role here (like in a security environment) I wonder if it wouldn't be easiest to employ a per-thread pseudo-RNG seeded with a different random number. One global RNG would be nice for this... GRand is such a pseudo-RNG. BTW: How often is gradient_fill_single_region_rgb being called? Maybe we can simply make the RNG a local property of this and the ..._gray function and be done with it; that of course wouldn't make much sense if it ends up being called a million times per fill... It is called once per tile. Your approach probably makes sense as long as don't use g_rand_new() but g_rand_new_with_seed(). g_rand_new() initializes the random number generator from /dev/urandom which is probably too expensive to be done once per tile. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and multiple processors
On 27.02.2005, at 15:19, Sven Neumann wrote: It is called once per tile. Your approach probably makes sense as long as don't use g_rand_new() but g_rand_new_with_seed(). g_rand_new() initializes the random number generator from /dev/urandom which is probably too expensive to be done once per tile. Incidentally this is exactly what I'm testing right now. ;=) Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] GIMP and multiple processors
On 27.02.2005, at 15:19, Sven Neumann wrote: It is called once per tile. Your approach probably makes sense as long as don't use g_rand_new() but g_rand_new_with_seed(). g_rand_new() initializes the random number generator from /dev/urandom which is probably too expensive to be done once per tile. Not too bad, here are the results (Patch in different mail): Before: Linear Gradient blend on a 3000x3000 pixel image (Dithering on) 1 processor:7.2 s 2 processors: 8.9 s Linear Gradient blend on a 3000x3000 pixel image (Dithering OFF) 1 processor:2.5 s 2 processors: 1.5 s After Linear Gradient blend on a 3000x3000 pixel image (Dithering on) 1 processor:7.0 s 2 processors: 3.6 s Linear Gradient blend on a 3000x3000 pixel image (Dithering OFF) 1 processor:2.6 s 2 processors: 1.4 s The degradation in the 1 processor setting without dithering seems to be a small measurement fluke in my last round since I consistently get better times in all other cases. Apologies for that. I need to think about a larger test image since its starting to get too difficult to time this microbench... Servus, Daniel PGP.sig Description: This is a digitally signed message part
[Gimp-developer] [Patch] Speed up blending code
Hija,
this is my suggested patch for getting the speeds improvements
as mentioned in the other thread by having a thread-local PRNG
initialized with a seed from the still existing blend tool local
RNG.
It looks bigger than it is because I took the liberty to remove
the nasty special casing on the existence of the RNG inside the
innermost loop because we now have it outside already.
There seems to be more room for obvious optimisations in the
loops. Also I would recommend splitting the two cases into
two separate functions to make the code easier to read, and
remove more conditionals.
PS: If this is okay, I'd do exactly the same for the gray
blending stuff...
diff -u -r1.155 gimpdrawable-blend.c
--- app/core/gimpdrawable-blend.c 26 Feb 2005 23:55:49 -
1.155
+++ app/core/gimpdrawable-blend.c 27 Feb 2005 14:55:36 -
@@ -1051,7 +1051,68 @@
gintendx = PR-x + PR-w;
gintendy = PR-y + PR-h;
gintx, y;
+
+ if (rbd-dither_rand)
+{
+ GRand *localrand = g_rand_new_with_seed (g_rand_int
(rbd-dither_rand));
+
+ for (y = PR-y; y endy; y++)
+ {
+ for (x = PR-x; x endx; x++)
+ {
+ GimpRGB color;
+ gdouble dither_prob;
+ gdouble ftmp;
+ gintitmp;
+
+ gradient_render_pixel (x, y, color, rbd);
+
+ ftmp = color.r * 255.0;
+ itmp = ftmp;
+ dither_prob = ftmp - itmp;
+
+ if (g_rand_double (localrand) dither_prob)
+ color.r += (1.0 / 255.0);
+
+ ftmp = color.g * 255.0;
+ itmp = ftmp;
+ dither_prob = ftmp - itmp;
+
+ if (g_rand_double (localrand) dither_prob)
+ color.g += (1.0 / 255.0);
+
+ ftmp = color.b * 255.0;
+ itmp = ftmp;
+ dither_prob = ftmp - itmp;
+ if (g_rand_double (localrand) dither_prob)
+ color.b += (1.0 / 255.0);
+
+ ftmp = color.a * 255.0;
+ itmp = ftmp;
+ dither_prob = ftmp - itmp;
+
+ if (g_rand_double (localrand) dither_prob)
+ color.a += (1.0 / 255.0);
+
+ if (color.r 1.0) color.r = 1.0;
+ if (color.g 1.0) color.g = 1.0;
+ if (color.b 1.0) color.b = 1.0;
+ if (color.a 1.0) color.a = 1.0;
+
+ *dest++ = color.r * 255.0;
+ *dest++ = color.g * 255.0;
+ *dest++ = color.b * 255.0;
+ *dest++ = color.a * 255.0;
+ }
+ }
+
+ g_rand_free (localrand);
+
+ return;
+ }
+
+ /* Fall-through for non-dithering case */
for (y = PR-y; y endy; y++)
{
for (x = PR-x; x endx; x++)
@@ -1059,46 +1120,6 @@
GimpRGB color;
gradient_render_pixel (x, y, color, rbd);
-
- if (rbd-dither_rand)
-{
- gdouble dither_prob;
- gdouble ftmp;
- gintitmp;
-
- ftmp = color.r * 255.0;
- itmp = ftmp;
- dither_prob = ftmp - itmp;
-
- if (g_rand_double (rbd-dither_rand) dither_prob)
-color.r += (1.0 / 255.0);
-
- ftmp = color.g * 255.0;
- itmp = ftmp;
- dither_prob = ftmp - itmp;
-
- if (g_rand_double (rbd-dither_rand) dither_prob)
-color.g += (1.0 / 255.0);
-
- ftmp = color.b * 255.0;
- itmp = ftmp;
- dither_prob = ftmp - itmp;
-
- if (g_rand_double (rbd-dither_rand) dither_prob)
-color.b += (1.0 / 255.0);
-
- ftmp = color.a * 255.0;
- itmp = ftmp;
- dither_prob = ftmp - itmp;
-
- if (g_rand_double (rbd-dither_rand) dither_prob)
-color.a += (1.0 / 255.0);
-
- if (color.r 1.0) color.r = 1.0;
- if (color.g 1.0) color.g = 1.0;
- if (color.b 1.0) color.b = 1.0;
- if (color.a 1.0) color.a = 1.0;
-}
*dest++ = color.r * 255.0;
*dest++ = color.g * 255.0;
Servus,
Daniel
PGP.sig
Description: This is a digitally signed message part
Re: [Gimp-developer] [Patch] Speed up blending code
From: Daniel Egger [EMAIL PROTECTED] Date: Sun, 27 Feb 2005 16:03:14 +0100 this is my suggested patch for getting the speeds improvements as mentioned in the other thread by having a thread-local PRNG initialized with a seed from the still existing blend tool local RNG. It looks bigger than it is because I took the liberty to remove the nasty special casing on the existence of the RNG inside the innermost loop because we now have it outside already. There seems to be more room for obvious optimisations in the loops. Also I would recommend splitting the two cases into two separate functions to make the code easier to read, and remove more conditionals. PS: If this is okay, I'd do exactly the same for the gray blending stuff... In addition to being very slow, this will also yield noisy results. There are a lot of dither algorithms that are both much faster and yield better results. While you may not need full-blown Floyd-Steinberg or EvenTone dithering for this purpose (and they're hard to use in a multi-threaded fashion), a simple dither matrix is fast, free of most artifacts, trivial to parallelize (you're only reading from the matrix, so no serialization is necessary), and reasonably low noise. In Gutenprint we have several precomputed matrices, designed for 1:1, 2:1, and 4:1 aspect ratios. You would need only a 1:1 ratio matrix. Also, our matrices are large (about 64K elements each, since they need 16 bit resolution), but you wouldn't need anything that big. There's a very simple iterated matrix that can generate any desired power of 2 matrix size (which makes for even faster lookup), but it does suffer from patterning. That may not matter for this purpose, since the steps are very small. We use the same matrix for all color channels, but offset the starting address for each channel to decorrelate the channels. Let me know if you're interested. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Patch] Speed up blending code
On 27.02.2005, at 16:42, Robert L Krawitz wrote: In addition to being very slow, this will also yield noisy results. There are a lot of dither algorithms that are both much faster and yield better results. While you may not need full-blown Floyd-Steinberg or EvenTone dithering for this purpose (and they're hard to use in a multi-threaded fashion), a simple dither matrix is fast, free of most artifacts, trivial to parallelize (you're only reading from the matrix, so no serialization is necessary), and reasonably low noise. This is just the first step to get better performance. In addition to the patch posted, I've already done and tested the separation of the dither and non-dither blending code, so it's a bit easier to simply change the algorithm from a randomized dither to a different one. If we also do the change to remove the local PRNGs with a global one which can be used to get a smaller number of pseudo-random numbers or to setup and seed a thread-local PRNG, the only needed change for your proposal would be to touch two or three (one for the setup) functions. Let me know if you're interested. Honestly I've no idea why the blending code does dithering at all; the dithering is completely invisible in 24bit RGB colorspace anyway. But if you can speed that up; be my guest... ;) Servus, Daniel PGP.sig Description: This is a digitally signed message part
[Gimp-developer] Re: [Patch] Speed up blending code
Hi, Daniel Egger [EMAIL PROTECTED] writes: There seems to be more room for obvious optimisations in the loops. Also I would recommend splitting the two cases into two separate functions to make the code easier to read, and remove more conditionals. All done already. I also got a nice improvement by rewriting the dithering code. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and multiple processors
On 27.02.2005, at 17:24, Sven Neumann wrote: Incidentally this is exactly what I'm testing right now. ;=) Incidentally that is what the code in CVS is doing. Looks like we were working on the same code. We should perhaps start using mutexes on the source code ;) Heh, you did not only do the same but you've chosen the exact same approach and function names... At least I have the performance figures you don't ;-p Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] GIMP and multiple processors
On 27.02.2005, at 17:19, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: As for your claim, dithering is completely invisible, try this image, which is done with gimp's blend and no dithering: http://data.plan9.de/d0.png That image features quite visible banding effects - you will have banding effects even if you go to 48 bit rgb, as the eye is very sensitive to banding. which has no banding effects, and is also much much bigger :) I had to compare very hard to see a difference at all, at least it's not clearly visible and you've chosen a pretty extreme case... But okay, I now believe in the power of dithering gradients ;) Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] newbie: how to scan lines?
Just to add a bit to Sven's response: balachandran c [EMAIL PROTECTED] writes: I am writing a plugin which requires comparing one row of pixels with the one following it. . . . how should it be done? There are lots of examples in the GIMP source that you can look at. Among the simplest is plug-ins/common/blur.c. One part of the algorithm involves quantizing the image, and the other involves user input. They are independent steps. Is it advisable to use one thread to launch the quantizing step, while the other waits for user input? Usually what I do in a situation like this is to have the time-consuming code at intervals execute a little chunk of code like this: while (gtk_events_pending ()) gtk_main_iteration (); This processes all Gtk+ events that have occurred since the last check, and then returns control to the function. Best, -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Patch] Speed up blending code
From: Sven Neumann [EMAIL PROTECTED] Date: Sun, 27 Feb 2005 17:29:52 +0100 Robert L Krawitz [EMAIL PROTECTED] writes: We use the same matrix for all color channels, but offset the starting address for each channel to decorrelate the channels. Let me know if you're interested. Yes, we are interested. I'd really like to get rid of the random number generator in the gradient blend code. It is simply way too slow and gradient blends are a rather frequent operation. OK. The code Daniel posted shouldn't be too hard to convert. The only thing it needs is to have the absolute row and column, to index into the matrix. Please have a look at the current code in CVS (will take a day for anoncvs to catch up). It is a lot more readable and should allow for easy replacement of the RNG by a dither matrix. Will I be able to compile it against a current (stable) GIMP installation? -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Patch] Speed up blending code
On 27.02.2005, at 20:01, Robert L Krawitz wrote:
OK. The code Daniel posted shouldn't be too hard to convert. The
only thing it needs is to have the absolute row and column, to index
into the matrix.
That hasn't made it into CVS because Sven was faster...
Here's the current code:
static void
gradient_fill_single_region_rgb_dither (RenderBlendData *rbd,
PixelRegion *PR)
{
GRand *dither_rand = g_rand_new_with_seed (g_rand_int (rbd-seed));
guchar *dest= PR-data;
gintendx= PR-x + PR-w;
gintendy= PR-y + PR-h;
gintx, y;
for (y = PR-y; y endy; y++)
for (x = PR-x; x endx; x++)
{
GimpRGB color;
gradient_render_pixel (x, y, color, rbd);
gradient_dither (dest, dither_rand, color.r);
gradient_dither (dest, dither_rand, color.g);
gradient_dither (dest, dither_rand, color.b);
gradient_dither (dest, dither_rand, color.a);
}
g_rand_free (dither_rand);
}
If needed you can setup your LUT globally or create it
on demand and have a pointer in RenderBlendData, depending
on how big and/or complex it is to compute and replace the
inner loop by your code.
Would it make sense to have several (selectable) dither
algorithms?
Will I be able to compile it against a current (stable) GIMP
installation?
Huh?
Servus,
Daniel
PGP.sig
Description: This is a digitally signed message part
Re: [Gimp-developer] [Patch] Speed up blending code
Hi,
Daniel Egger [EMAIL PROTECTED] writes:
for (y = PR-y; y endy; y++)
for (x = PR-x; x endx; x++)
{
GimpRGB color;
gradient_render_pixel (x, y, color, rbd);
gradient_dither (dest, dither_rand, color.r);
gradient_dither (dest, dither_rand, color.g);
gradient_dither (dest, dither_rand, color.b);
gradient_dither (dest, dither_rand, color.a);
}
Should probably note that
gradient_dither (dest, rng, value)
expands to
{
gdouble ftmp = value * 255.0;
gintitmp = ftmp;
if (g_rand_double (rng) ftmp - itmp)
*dest++ = itmp;
else
*dest++ = MIN (itmp + 1, 255);
}
Sven
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP fails to compile without C++ compiler?
In regard to: Re: [Gimp-developer] GIMP fails to compile without C++...: Daniel Egger [EMAIL PROTECTED] writes: just curious, is it expected that configuration of a GIMP build will fail if configure cannot find a C++ compiler? That question would better be asked on the autoconf list. While you are on it, ask them why there are checks for a fortran compiler. I don't think we ask for any of those. As Yosh has already replied, this is a problem in libtool. I thought a fix had been applied to the 1.5 branch, but I can't seem to find it so it must be in the 2.0 branch only. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and multiple processors
On Sun, 2005-02-27 at 01:04 +0100, Sven Neumann wrote:
Hi again,
Jay Cox [EMAIL PROTECTED] writes:
Clearly the gradient code could use some tuning. A linear blend
shouldn't take much more than 1/2 a second even with dithering.
Could we improve this by preparing a reasonably fine array
of samples and picking from these samples instead of calling
gimp_gradient_get_color_at() over and over again?
That is one obvious optomization.
Other obvious optomizations:
The dither code is way too complex. It looks like it should boil down
to: color.{r,g,b,a} += g_rand_int()/RAND_MAX.
We shouldn't need 32 bits of random data per component. 8 bits should
do, so we only need one call to g_rand_int per pixel.
For linear blends we should calculate delta values for the factor
variable. This will allow us to calculate the factor for each pixel
with only one add (plus edge condition checks).
The reason why the dithering case gets less of a speedup is because
the threads are fighting over the GRand state. Each thread needs to
have it's own GRand state.
It looks like the threads are also fighting over
gradient-last_visited. My guess is that fixing this will get us
much closer to the ideal 2x speed up.
I have eliminated last_visited from the gradient struct. Instead the
caller of gimp_gradient_get_color_at() may now do the same
optimization without any caching in the gradient itself. I very much
doubt that this makes any difference though. Perhaps if you would
benchmark a gradient blend with a lot of segments. But in the general
case it's just a few of them, very often even only a single one.
Now that this race condition is eliminated I might look into adding
hooks to the pixel-processor to allow initialisation of per-thread
data, like for example a GRand.
I think that is the correct way to do it. It should be done generaly
enough so that the histogram code can be moved over to use the
pixel_region_process_parallel functions.
Jay Cox
[EMAIL PROTECTED]
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and multiple processors
Hi, Jay Cox [EMAIL PROTECTED] writes: Now that this race condition is eliminated I might look into adding hooks to the pixel-processor to allow initialisation of per-thread data, like for example a GRand. I think that is the correct way to do it. It should be done generaly enough so that the histogram code can be moved over to use the pixel_region_process_parallel functions. The histogram code does already use the threaded pixel-processor. You think we could simplify the code? IMO the current solution isn't all that bad. But I haven't benchmarked it so I don't really know... I tried to introduce the per-thread initialization code today but figured that it adds quite some complexity. It could certainly be done but I don't see much need for it any longer. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and multiple processors
On 28.02.2005, at 00:25, Sven Neumann wrote: The histogram code does already use the threaded pixel-processor. You think we could simplify the code? IMO the current solution isn't all that bad. But I haven't benchmarked it so I don't really know... I tried to introduce the per-thread initialization code today but figured that it adds quite some complexity. It could certainly be done but I don't see much need for it any longer. The first goal should be to reduce complexity. Today I looked into parallelizing some *really* slow code: supersampling. Activating it slows down the processing *much* more than just the factor of the supersampling depth. And hey, the code is uglee at least a top candidate for the ugliest code left in The GIMP. NB: Not that I had any idea what supersampling might be good for in the case of gradients, but what do I know... Servus, Daniel PGP.sig Description: This is a digitally signed message part
