Design issues (opengl, hdr, channels, pigment(?))

[Cyrille Berger]

> > > I think we should go the getTexture() and writeTexture() route.
> >
> > what is this route ?
>
> (blahblah)
ah ok, it's for display only ?

> > see below (at the end of my comment on pigment), I think the QBitArray
> > solution, after all, we didn't even choose the solution to enforce
> > KisSelection...
>
> I think there's something missing in this sentence :-). But if I fill in
> the gaps correctly, you prefer the bit array solution? Do we need to make
> it automatic to have a filter configuration per channel for all filters?
hum, it's my turn to be unsure about the question :/ Yes I prefer the bit 
array solution. I don't think enforcing it is a good idea. I don't see the 
use for a per channel configuration for a red eye removal filter, for 
instance.

> > Not much has change you know ;) It's just that instead of calling a
> > virtual function of the colorspace, you call a virtual function of a
> > transformation object that you did created with a call to a function of
> > the colorspace. This allow us to dynamically creates operations and
> > choose the best one for the CPU or the task at hand (I am thinking that
> > this might be a possibility to keep fast implementation for the previous
> > point, I need to think a little bit more about it).
>
> We could have the factory function make the choice using kcpuinfo and a
> configuration parameter for opengl (because opengl is fast but inaccurate
> we cannot mandate it); that way the object returned always is the fastest
> version.

I also saw some library that where doing some timing of the 
various "algorithms" at startup to determine which algorithm was fastest for 
the specific hardware.

> > Now, we need to think if we need or if we want to have extensibility of
> > those operations.
>
> You mean make it possible to add functionality to colorspaces using
> plugins?
Yes something like that.

> Then we'd need to have a kind of per-colorspace registry of ops 
> that the colorspace can query to get the asm, plain-software or opengl
> variant of an op.
Hum yes.

Note: I don't favor seeing more asm in krita, I don't think the speed 
improvement is worth the few drawbacks: decrease of code readability, not 
portable and not that maintanable. I think C/C++ is fast enought (and we can 
use MMX/SSE/SSE2 instructions in C/C++, I need to resume my work in that 
area, but my last attempt was with an algorithm that can't be accellerated 
with them :/ ).
-- 
Cyrille Berger