bitBlt

[Boudewijn Rempt]

The bitBlt code in KisPainter now uses an iterator over the area that's to be 
blitted to call for each seperate pixel a compose function. I thought that 
maybe it would be faster to to call the color strategy compose functions for 
larger block of pixels, but on the other and, it would simplify code a lot if 
the color strategies didn't need to do their own loops inside blocks of pixel 
memory.

How about changing:

	/**
	 * Compose two arrays of pixels together. If source and target
	 * are not the same colour model, the source pixels will be
	 * converted to the target model.
	 */
	virtual void bitBlt(Q_INT32 stride,
			    QUANTUM *dst, 
			    Q_INT32 dststride,
			    KisStrategyColorSpaceSP srcSpace,
			    QUANTUM *src, 
			    Q_INT32 srcstride,
			    QUANTUM opacity,
			    Q_INT32 rows, 
			    Q_INT32 cols, 
			    CompositeOp op,
			    KisProfileSP srcProfile = 0,
			    KisProfileSP dstProfile = 0);


to:


	/**
	 * Compose two pixels together. If source and target
	 * are not the same colour model, the source pixel will be
	 * converted to the target model.
	 */
	virtual void compose(QUANTUM *dst, 
			     KisStrategyColorSpaceSP srcSpace,
			     QUANTUM opacity,
			     CompositeOp op,
			     KisProfileSP srcProfile = 0,
			     KisProfileSP dstProfile = 0);

?

It shouldn't be any slower than it is now, but on the other hand, it will make 
it hard to optimize things like COMPOSITE_COPY or COMPOSITE_CLEAR, which work 
a lot faster if they can act on as big a chunk of memory as possible.

And it would make the color strategy code a lot simpler.

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20050201/69095117/attachment.pgp