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

[Cyrille Berger]

> > Which means, that we would need to have two plugins
> > implementation, one for
> > opengl and one for C++/mmx ?
>
> Why do you always need both implementations? Why not
> always provide a general/slow C++ one and if there is
> the need for a faster plugin, provide the openGL one
> as well. Let krita dynamically decide which plugin is
> best to use...

That makes two implementations ;) (two implementation for each plugin that can 
be "openglised"). What I hoped we could do in the filters was:

KisSomeOperation* op = colorSpace->constructSomeOperation();

while(I can iterate)
{
	op->transform(mypixelsfrommyiterator);
}

and have constructSomeOperation return the fastest implementation. On the 
other hand, as OpenGL seems to give inaccurate results, maybe having two 
plugins is better (like "fast but inaccurate blur" "slow but accurate blur", 
or add KisFilter::fastProcess(blabla); and use OpenGL only for previewing, 
while the correct transformation is applied on background)

> > 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.
>
> Sorry if this is neive but doesn't GCC already do
> autovectorization and can optimize using mmx if the
> correct compiler flags are used? (looks like pentium2
> and higher)
> Wouldn't it be better just to write the code to be as
> clean as possible and check the resulting asm with all
> of the optimization flags turned on?
Because of :

http://lists.kde.org/?l=kde-kimageshop&m=116603817419705&w=2
and especially:
http://lists.kde.org/?l=kde-kimageshop&m=116591635104447&w=2


-- 
Cyrille Berger