Commit by mosfet :: r705167 cmake/trunk/KDE/kdelibs/cmake/modules/FindBlitz.cmake:

Another fix for Dirk's change...

Commit by mosfet :: r705165 /trunk/kdesupport/CMakeLists.txt:

Fix Dirk's change ;-)

Commit by mosfet :: r705126 blitz/trunk/kdesupport/blitz/blitz/ (blitz_export.h qimageblitz_export.h):

Maybe I should of waited till morning to do this >:)

Commit by mosfet :: r705121 blitz/trunk/kdesupport/blitz/blitz/ (blitz.pc.cmake qimageblitz.pc.cmake):

Forgot this, sorry - 3:30am here and just got home from work >:)

Commit by mosfet :: r705111 krita/trunk/koffice/krita/ui/kis_prescaled_projection.cpp:

Use new header name.

Commit by mosfet :: r705110 kolourpaint/trunk/KDE/kdegraphics/kolourpaint/imagelib/effects/ (3 files):

Use new header name.

Commit by mosfet :: r705108 cmake/trunk/KDE/kdelibs/cmake/modules/FindBlitz.cmake:

Use new name,

Commit by mosfet :: r705107 blitz/trunk/kdesupport/blitz/ (14 files in 3 dirs):

Changed header and lib name as per:

http://lists.kde.org/?t=118812756900003&r=1&w=2&n=6

Commit by mosfet :: r704530 blitz/trunk/kdesupport/blitz/blitz/private/ (blitz_p.h interpolate.h):

More modernizinating :) Far more efficient than it was before and
from the test app looks like better results as well.

Commit by mosfet :: r703817 blitz/trunk/kdesupport/blitz/blitz/private/ (blitz_p.h interpolate.h):

Decrapifying old KImageEffect/ImageMagick based code.

Commit by mosfet :: r703600 blitz/trunk/kdesupport/blitz/blitz/ (3 files):

Apple's external assembler seems not to handle a
lot of opcodes. MySQL had the same problem:
http://bugs.mysql.com/bug.php?id=18470

We do what they do and just disable it for now.
Note that this only applies to external asm files,
inline asm works fine. Matt Broadstone is looking
for a better solution.

As usual with CMake, I think this is correct but
probably is not ;-)

Commit by mosfet :: r702888 blitz/trunk/kdesupport/blitz/blitz/gradient.cpp:

Changed multidimensional arrays to singledimensional in
preparation for QVarLengthArray.

I believe these are the largest allocations made by Blitz:
3 rows and 3 columns. Nonetheless that still should be small
enough for stack-based allocation and I would think.

Commit by mosfet :: r702863 blitz/trunk/kdesupport/blitz/blitz/ (3 files):

Remove the math.h test.

Commit by mosfet :: r702634 blitz/trunk/kdesupport/blitz/blitz/ (5 files in 2 dirs):

Try using the C++ math routines. Quickly tested it and it seems alright. If there
is no problems I will remove the CMake checks in a little bit.

BTW: I used the full std:: namespace specification because I both wanted to
be clear what was being used and find "::" with no namespace hard to read
in the middle of a long equation :P

Commit by mosfet :: r702292 blitz/trunk/kdesupport/blitz/blitz/gradient.cpp:

Might as well be correct about these, too.

Commit by mosfet :: r702291 blitz/trunk/kdesupport/blitz/blitz/gradient.cpp:

Last MSVC fix caused a segfault. Do it the old, verbose way >:)

Commit by mosfet :: r702276 kdeui/trunk/KDE/kdelibs/kdeui/widgets/ (2 files):

Get rid of KImageEffect.

Commit by mosfet :: r702268 /trunk/KDE/kdebase/CMakeLists.txt:

Adding the Blitz dep, as per:
http://lists.kde.org/?l=kde-core-devel&m=118735498607098&w=2

Commit by mosfet :: r701804 blitz/trunk/kdesupport/blitz/ (6 files in 2 dirs):

More gradient work, mostly to support 8bpp grayscale gradients
but some other cleanups as well.

Some of you are probably wondering why I'm spending effort on
the gradient code now that Qt supports them. The most important
reason is the unbalanced gradients. In this case "unbalanced" refers
to the line of the gradient, not it's color transition, and can't
be replicated with Qt gradients. For example, if you make a diagonal
gradient with a positive unbalance factor it will appear to curve
to the bottom-right. This can be used for emulating a shadow or
highlight and other neat stuff. You can't do this with QLinearGradient,
which will always draw the gradient on a line.

The other reason is also the reason for this commit. Some applications
blend two images, or an image and a color, using a gradient. That's what
most of those blend() methods in KImageEffect were for. Now you can
get 8bpp grayscale gradients by calling grayGradient() or
grayUnbalancedGradient() and use them for an image's alpha channel. These
are drawn natively and don't create a 32bpp temporary image. This
is far more efficent than what you would otherwise do with Qt.

The other reasons are minor. The gradients should be slightly faster but
that really matters only if your doing something like using them as a background
for a resizable widget and need to recalculate them often. Another reason is the
oddball gradient types like Pyramid that some applications use, but probably
can be depreciated. I'm not gonna suggest that, tho... I already unintentionally
started one flamewar suggesting we depreciate things >:)

Anyways, this commit adds grayGradient() and grayUnbalancedGradient(), moves the
gradients to their own source file to be better organized, and has a few minor
cleanups.

Commit by mosfet :: r701583 kdeui/trunk/KDE/kdelibs/kdeui/widgets/kpixmapregionselectorwidget.cpp:

Ported off of KImageEffect to plain Qt, but still uses the
KImageEffect::RotateDirection enum. That will have to wait
until Monday.