Making kdefx static

Mosfet daniel.duley at
Sat Aug 4 12:50:35 BST 2007

<Pino Toscano wrote:>
Okular just uses KImageEffect::flatten(), for usability purposes. In case, I 
can keep a local copy of it. (Luckly, it does not depend on any other 
</Pino Toscano> 

Actually, I was planning on depreciating flatten() and wasn't planning on 
porting it. It's rather expensive for what it does, taking the graylevel of 
the entire image then using floating point math again on the entire image to 
repaint it as a bitmap. Better to use something else like the below 

Which brings me to a more important issue in KImageEffect: all the blend() 
methods. These take up a huge part of KImageEffect and I am not planning on 
keeping them for Blitz or Quasar. For both raster operations and blending 
stuff QPainter on a QImage is really efficent now. If your like me you 
probably balk at first at using a QPainter just to do a simple alphablend or 
overlay, but the stuff has been really heavily optimized. If you don't 
believe me take a gander at Qt's src/gui/painting/qdrawhelper* and raster 
paint engine. Unbelievable goodness.

This means people probably need to start porting code that uses the following 
to QPainter on a QImage *now*:


Most of these methods were used simply to highlight an image or icon. I'd 
replace it with something that draws over them with a non-opaque brush.

Rotate() has been removed because QImage::transformed() now has special cases 
for right angles. These should perform fine. I've kept gradient() because it 
should be *a little* more efficent than QLinearGradient for now. For normal 
use it doesn't matter but when used for things like resizable backgrounds it 
does. This could also be solved by special cases in Qt as well, (if it 
already has these I apologize - I didn't see them).

I've also depreciated hash(), solarize(), addNoise(), shade(), and bumpmap().

OTOH I've ported and readded desaturate(), channelIntensity(), and fade().

If people have many objections to the above depreciated functions I can port 
them for backwards compatibility, but I'd rather not. They wouldn't have the 
same amount of testing as the methods I've actually been using all this time 
and they don't have real maintainers.

More information about the kde-core-devel mailing list