blitz

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

Mon, 27 Aug 2007 08:39:58 +0000

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 >:)

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

Mon, 27 Aug 2007 08:29:48 +0000

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 >:)

Changed header and lib name as per:...

Mon, 27 Aug 2007 07:32:19 +0000

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

Don't hardcode lib version in pc file

Sun, 26 Aug 2007 16:58:42 +0000

Commit by mlaurent :: r704933 blitz/trunk/kdesupport/blitz/blitz/ (CMakeLists.txt blitz.pc.cmake):

Don't hardcode lib version in pc file

fix build issue

Sat, 25 Aug 2007 12:45:47 +0000

Commit by whiting :: r704574 blitz/trunk/kdesupport/blitz/blitz/gradient.cpp:

fix build issue

More modernizinating :) Far more efficient than it was before and from the test...

Sat, 25 Aug 2007 09:05:41 +0000

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.

Decrapifying old KImageEffect/ImageMagick based code.

Thu, 23 Aug 2007 11:47:46 +0000

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

Decrapifying old KImageEffect/ImageMagick based code.

Don't try to compile asm file. ".size" is not supported by as from windows.

Thu, 23 Aug 2007 08:56:27 +0000

Commit by mlaurent :: r703770 blitz/trunk/kdesupport/blitz/blitz/CMakeLists.txt:

Don't try to compile asm file. ".size" is not supported by as from windows.

Use directly INCLUDE_INSTALL_DIR which defined includedir for blitz

Thu, 23 Aug 2007 07:18:12 +0000

Commit by mlaurent :: r703745 blitz/trunk/kdesupport/blitz/blitz/blitz.pc.cmake:

Use directly INCLUDE_INSTALL_DIR which defined includedir for blitz

Defined to 1 as wrote in comment

Thu, 23 Aug 2007 07:15:27 +0000

Commit by mlaurent :: r703743 blitz/trunk/kdesupport/blitz/blitz/ (2 files):

Defined to 1 as wrote in comment

Apple's external assembler seems not to handle a lot of opcodes. MySQL had the...

Wed, 22 Aug 2007 22:59:07 +0000

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 ;-)

Changed multidimensional arrays to singledimensional in preparation for...

Tue, 21 Aug 2007 12:39:13 +0000

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.

Remove the math.h test.

Tue, 21 Aug 2007 11:19:24 +0000

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

Remove the math.h test.

Try using the C++ math routines. Quickly tested it and it seems alright. If...

Mon, 20 Aug 2007 23:08:25 +0000

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

Fix check for expf: it comes from libm.

Mon, 20 Aug 2007 19:36:53 +0000

Commit by dfaure :: r702536 blitz/trunk/kdesupport/blitz/blitz/CMakeLists.txt:

Fix check for expf: it comes from libm.

On those platforms that do not have math functions which work on floats, e.g.,...

Mon, 20 Aug 2007 17:03:45 +0000

Commit by sevans :: r702447 blitz/trunk/kdesupport/blitz/blitz/ (7 files):

On those platforms that do not have math functions which work
on floats, e.g., expf, use the functions that work on doubles
instead.

Might as well be correct about these, too.

Mon, 20 Aug 2007 10:39:32 +0000

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

Might as well be correct about these, too.

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

Mon, 20 Aug 2007 10:37:19 +0000

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

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

fix msvc compilation / remove gcc specific language extension

Sun, 19 Aug 2007 21:10:30 +0000

Commit by chehrlic :: r701992 blitz/trunk/kdesupport/blitz/blitz/gradient.cpp:

fix msvc compilation / remove gcc specific language extension

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

Sun, 19 Aug 2007 12:02:05 +0000

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.