API change proposal for pigment's KoColorSpace

[Bart Coppens]

On Thursday 30 November 2006 20:47, Cyrille Berger wrote:
>  - some functions are not reentrent (and therefor not thread safe), mostly
> color conversion
With lcms not being quite threadsafe itself, that's a bit hard to achieve 
anyway, you'd have to use a per-thread profile (or a mutex on the profile 
handle) or so.

>  - but most important, there is no easy (and efficient) way to automaticaly
> turn on optimization at runtime (opengl shaders and mmx/sse)
Interesting idea, yes. I like it. Beware, though, I've been told that for 
opengl, it's best that we'd keep the data in the graphics card for as long as 
possible. And that's not really feasible with our design, I think. But it's 
what I've been told, I don't know the details myself.

> I propose that we follow a similar approach than the one of composite
> operation. Instead of calling a function of the colorspace to do an
> operation, that the colorspace return us an object with the function. For
> instace:
> [...]
Since that's already in the line of what we do a bit with both the composite 
ops, and the KisColorAdjustment, I think this looks pretty appropriate.

> As for colorspace convertion (which are the function guilty of non
> reentrability), I am hesitating between using mutex for access to the cache
> of color transformation or to have a factory of KoColorConvertionOp and
> have a cache for each thread.
Yes exactly, but I think 'convertion' is a bit too narrow a term for this, 
since afaik it also is a problem with transformations. Personally, I think I 
like the idea of having a per-thread cache, if that can be done efficiently 
with the threadweaver thing. Using a mutex on this kind of thing defeats the 
primary purpose of multithreading this anyway, since most of the time will be 
spent in these routines (I think, empirical verification could be needed ;)).

Bart