API change proposal for pigment's KoColorSpace

[Boudewijn Rempt]

On Thursday 30 November 2006 23:41, Bart Coppens wrote:
> 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.

It's not the profile that's the problem, as far as I understand it, but the 
transform itself -- we share the transform handles because a transform can be 
both big and slow to create. But Marti is working on that.

> 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, then it should be in our tile backend. Only if 
tiles can store their data in textures, we'll be able to really make good use 
of OpenGL. And then we'll have to have a triple cache: on-card, in-memory, 
in-memory compressed, swapped-out. But it may be worth it.

I don't think that this means we will have to expose tiles to filters and 
colorspaces, since all runs of pixels we give to the colorspace functions are 
inside one tile/texture anyway. How that works out exactly I don't know.

> > As for colorspace conversion (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 '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.

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20061201/ac8d6085/attachment.pgp