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

Reply via email to