On Mon, 2005-02-28 at 00:25 +0100, Sven Neumann wrote: > Hi, > > Jay Cox <jaycox@xxxxxxxx> 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 jaycox@xxxxxxxx PS: Shouldn't we be ignoring all this stuff and working on gegl? ;)
