On Mon, 2005-02-28 at 00:25 +0100, Sven Neumann wrote:
> 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.
PS: Shouldn't we be ignoring all this stuff and working on gegl? ;)
Gimp-developer mailing list