bitBlt

[Casper Boemann]

On Tuesday 01 February 2005 09:57, Boudewijn Rempt wrote:
> 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.

I would kind of prefer if we kept it, because I need it to optimize blitting 
the way I intend. At least until we see if my optimization is worth the 
complexity.

best regards
Casper Boemann