Re: [Gimp-developer] GIMP and multiple processors
On Mon, 2005-02-28 at 00:25 +0100, Sven Neumann wrote: 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... Of course you are correct. I guess it has been a while since I looked at that code... It reads like an clever hack, not elegant design. 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. I think per-thread initialization and finalization would make the histogram code much cleaner (and slightly faster and more scaleable). It should also let us more easily paralellize a wider selection of algorithms (not that I can think of any off the top of my head...). Any thoughts on moving some of the _process_parallel stuff to libgimp? I think it would be cool if we could integrate it with the preview code. Jay Cox [EMAIL PROTECTED] PS: Shouldn't we be ignoring all this stuff and working on gegl? ;) ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: GIMP and multiple processors
Hi, [EMAIL PROTECTED] (2005-02-28 at 0211.21 +0100): NB: Not that I had any idea what supersampling might be good for in the case of gradients, but what do I know... High frequency gradients or abrupt changes, compare the yellow - black transition in left side with the one in right side of http://www.infernal-iceberg.com/gimp/tmp/gradient-supersampling-crop.png Of course, it depends in the display and the eyes/brain, some people see the problem more than others. Same issue than with dithering, it depends with the case. GSR ___ 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, Daniel Egger [EMAIL PROTECTED] writes: 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. Since supersampling is in libgimpcolor, it will probably be difficult to improve without breaking backwards compatibility. But of course noone forces us to actually use the functionality in libgimpcolor... 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 21:15, Sven Neumann wrote: Since supersampling is in libgimpcolor, it will probably be difficult to improve without breaking backwards compatibility. But of course noone forces us to actually use the functionality in libgimpcolor... But, and this is one of many upsides of improving library code, all users of supersampling will benefit at the same time. Maybe it would be best if someone could come up with a reasonable example what supersampling might be useful for in gradient blend code except for slowing down everything... Servus, Daniel PGP.sig Description: This is a digitally signed message part
[Gimp-developer] Re: GIMP and multiple processors
Maybe it would be best if someone could come up with a reasonable example what supersampling might be useful for in gradient blend code GSR (?) already gave such an example. It might be worth considering only supersampling when the end of a segment is a different color than the start of the next one. ___ 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:
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.
Good point. This made a lot of a difference. The dithered case is now
only about 10% slower than the non-dithered one :)
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
Daniel Egger wrote: Maybe it would be best if someone could come example what supersampling might be useful for in gradient blend code except for slowing down everything... For an A-B linear blend it probably doesn't noticably help much (unless, possibly, it's a long colour range in a small area). But GIMP gradients *can* be fairly arbitrary user-defined 1D designs including near-discontinuities, which benefits from supersampling in the same way that a stroke, line or polygon benefits from antialiasing. --Adam -- Adam D. Moss - [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
