State of kdefx

[Zack Rusin]

On Friday 20 July 2007 06:22:33 am Mosfet wrote:
> Hey, I see you all are finally noticing kdefx is broken again ;-)
>
> If you search the archive you'll noticed I offered to do a huge update to
> this back in *2005* with both bugfixes and lots of MMX acceleration,
> (including a new MMX accelerated convolve). Regretfully Zack and I got into
> a big flamefest and it was rejected, not because of the code but because we
> couldn't seem to agree on anything. Search for the author "mosfet" to check
> it out.
>
> Since then we resolved our differences and he was supposed to be doing a
> new library, (it's somewhere in SVN), and I was supposed to add my filters
> to his lib with KImageEffect being dropped. I'm still more than willing to
> do this and but haven't heard anything from him in about 4 months.

Hey :) Yeah, I apologize again for not being the most reliable email contact 
especially during the last few months. 

I haven't elaborated my opinion on the effects library up til now, mainly 
because, well, I forgot and simply had to handle a lot of other things. 

As you remember, we had some issues with the design of KImageFx when we were 
working on it. To me it became very apparent that to create a proper 
filtering pipeline a graph based approach like the one described in:
"A model for efficient and flexible image computing" 
http://portal.acm.org/citation.cfm?id=192191 and implemented to a certain 
degree in CoreImage would be needed. This is why I had to leave the 
architecture of KImageFx and redo it from scratch in form of Quasar.

I think the biggest problem with this stuff is that I work on it in a private 
git repo and should push it somewhere so that people can pull it and play 
with it. I just didn't feel it's ready. I'll try to remedy this situation in 
the coming week.

As to what to do with kdefx, I honestly don't feel we need to have image 
manipulation library in kdelibs for 4.0. 

So personally I just feel it makes way more sense to do it properly for 4.1 
rather than just put something in for 4.0. It's just not a showstopper for 
4.0 and applications/libraries that require some image effect as part of some 
core functionality can just copy and paste the given effect in. 
These applications will likely require something very special and instead of 
trying to frantically get a whole image manipulation framework ready and 
optimized for 4.0 (at, in my experience, great expense to its API) we can 
simply give ourselves a little bit of extra time and do it properly for 4.1.

z