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

[Boudewijn Rempt]

On Tuesday 30 January 2007, Cyrille Berger wrote:
> > > > I think we should go the getTexture() and writeTexture() route.
> > >
> > > what is this route ?
> >
> > (blahblah)
>
> ah ok, it's for display only ?

No! It may have sounded like blabla, but that's quite the wrong conclusion 
from what I wrote. I'm experimenting with using shaders in a Krita plugin 
right now but I'm already sure that our iterator based approach to image data 
does not work for anything that uses opengl.

I mean: we use iterators to get as large as possible chunks of bytes that we 
pass to the colorspaces who segment it into pixels and do stuff with those 
pixels. That's fine for C++ and for mmx and similar. These are fairly small 
1d arrays.

OpenGL needs to load the data into 2d textures (for preference) that are still 
often constrained to power-of-2. And bigger and fewer textures are better 
from a performance point of view. So, if we want to convolve with opengl, 
filter with opengl or do anything else with opengl (and I want to, it's 
fascinating me), then we need to be able get the paint device data as 
efficiently as possible into textures.

My provisional conclusion from the experiment I'm working is that the opengl 
operations cannot have the same api as the c++ or mmx operations and that we 
need a separate architecture to expose paint device data to opengl. I'm 
taking nvidia's photoshop opengl sdk as an exampole for what I think will be 
needed.


> 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.

Okay. I think I need to put down all the issues and variables for this thing 
to see whether we can have a good design. I'll do that in answer to Ben's 
mail.

> 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.

That would be cool!

> 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 :/ ).

mmx and similar (used in C++, that would be better indeed) are especially 
worthhwile for the composite ops. Those are very parallizable, simple and 
used a lot. We might nick the Gimp's code for composition in mmx etc. 
(Although now I think of it -- those are maybe plain asm files again. I'll 
check.)

-- 
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/20070201/1a1b53b8/attachment.pgp