Making kdefx static
Mosfet
daniel.duley at verizon.net
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
functions.)
</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
suggestion.
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*:
blend()
blendOnLower()
flatten()
modulate()
selectedImage()
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