[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice-devel
Subject: Re: API change proposal for pigment's KoColorSpace
From: Boudewijn Rempt <boud () valdyas ! org>
Date: 2006-11-30 23:16:29
Message-ID: Pine.LNX.4.63.0612010014160.6412 () calcifer ! valdyas ! org
[Download RAW message or body]
On Thu, 30 Nov 2006, Cyrille Berger wrote:
> 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:
That's something that I started to do a year or so ago, but I got bogged down
with other stuff so it never got committed. But, yes, I think that it would
be a good idea.
> 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.
I was already aware of the problem, and I was leaning towards the latter, coupled
with a threadpool of "ready" threads, waiting for conversion requests. Note however
that the lcms colorspace conversion functions are not completely thread-safe either,
although Marti is working on it.
Boudewijn
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic