API change proposal for pigment's KoColorSpace
Cyrille Berger
cberger at cberger.net
Thu Nov 30 20:47:25 CET 2006
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 ---
More information about the kimageshop
mailing list