koffice/krita

[Casper Boemann]

yes I'm working on that

real life is just a bitch right now so I havn't had time to test it yet.

and yes your suggestion sounds right on. But given that we typically work on
tiles that may not be aligned, the effect is not that great. Most lowlevel
copies would only be about 128 byte chunks on average, but still it's better
than one at a time.

best regards
Casper Boemann

----- Original Message ----- 
From: "Cyrille Berger" <cyb at lepi.org>
To: "For developers of Krayon (previously known as KImageShop)"
<kimageshop at kde.org>
Sent: Monday, August 30, 2004 12:08 PM
Subject: Re: koffice/krita


> > Currently one of the advantages of working with larger chunks of image
is
> > that operations like the COMPOSITE_COPY and COMPOSITE_OVER where opacity
==
> > OPACITY_OPAQUE can just memcpy the whole chunk, leading to better
> > performance.
> I was thinking about that, with the IterratorsRect (btw, is someone
working on
> them ?) we can have a function that do a memcpy, this will hide the
quantum
> to compositeop, which would have this prototype :
> compositeOp(KisIterratorsRect dst, KisIterratorsRect srcBegin,
> KisIterratorsRect srcEnd, QUANTUM opacity)
>
> And for instance composite copyt would look like this :
> compositeCopy(KisIterratorsRect dst, KisIterratorsRect srcBegin,
> KisIterratorsRect srcEnd, QUANTUM opacity)
> {
> if(opacity == OPACITY_OPAQUE)
> {
> dst.memcpy( srcBegin, srcEnd);
> }
> else {
> ...
> }
> }
>
> This will hide the QUANTUM* and TileMgr to the strategy, which is
something we
> were wanting to achieve.
>
> -- 
> --- Cyrille Berger ---
> _______________________________________________
> kimageshop mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>
>