API change proposal for pigment's KoColorSpace

[Cyrille Berger]

Hi,

I will give the list of issues with the current API :

 - some functions are not reentrent (and therefor not thread safe), mostly 
color conversion
 - but most important, there is no easy (and efficient) way to automaticaly 
turn on optimization at runtime (opengl shaders and mmx/sse)

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:

class KoMixColorOperation {
 virtual void mixColors(const quint8 **colors, const quint8 *weights, quint32 
nColors, quint8 *dst) const = 0;
}

class KoColorspace {

	KoMixColorOperation* mixColorOp();
}

And then we have KoMixColorOperationImplementedInVeryCoolShaders and 
KoMixColorOperationImplementedWithVeryCoolMMX. And at the construct time of 
the colorspace, this one is capable to dertemine which operation will be 
faster depending on what the hardware offer.

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.

Any though opinion ?

-- 
--- Cyrille Berger ---