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

[Cyrille Berger]

On Thursday 01 February 2007, Boudewijn Rempt wrote:
> 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,
Sorry, I didn't mean to offense you !

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

Which means, that we would need to have two plugins implementation, one for 
opengl and one for C++/mmx ?

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

But quiet impossible if opengl and C++/mmx doesn't share the smae kind of  API 
than Ko{Color|Convolution|Mix|Whatever}Transformation API.

> > 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.)
Yes it's plain asm files, so we don't want them :) I am still working on the 
library that would allow us to have the same implementation for mmx/sse and 
normal instruction.

-- 
Cyrille Berger