API change proposal for pigment's KoColorSpace

[Cyrille Berger]

> > 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.
>
> If we're serious about opengl, (...)
Well we are :) at least the architecture should be open for it.

> > Yes exactly, but I think 'conversion' 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 ;)).
>
> Yes, indeed. Mutexes make the whole thing serialized anyway.

Here is what I propose :

class KoColorTransformationOperation {

virtual void transform(const quint8 *src, quint8 *dst, qint32 nPixels) const = 
0;
}

virtual KoColorTransformationOperation 
*createBrightnessContrastAdjustment(quint16 *transferValues) const = 0;
virtual KoColorTransformationOperation *createDesaturateAdjustment() const = 
0;
virtual KoColorTransformationOperation *createPerChannelAdjustment(quint16 
**transferValues) const = 0;
virtual KoColorTransformationOperation *createConvertOperation(const 
KoColorSpace * dstColorSpace,  qint32 renderingIntent = INTENT_PERCEPTUAL) 
const = 0;

Then it's up to the thread to keep a cache of the operations he wants/needs to 
keep.

-- 
--- Cyrille Berger ---