Optimization for the duplicate paintop

Casper Boemann cbr at boemann.dk
Tue May 30 10:54:23 CEST 2006


sounds like a possibillity, but do think it trough and test it with inverted 
selections.

----- Original Message ----- 
From: "Cyrille Berger" <cberger at cberger.net>
To: "Krayon (KImageShop)" <kimageshop at kde.org>
Sent: Tuesday, May 30, 2006 10:39 AM
Subject: Re: Optimization for the duplicate paintop


>> The drawback is that the rect then is aligned with tile boundaries --  
>> which
>> means that it is larger than the rect really is. This may not matter too
>> much in this particular case. It means that more pixels are considered 
>> for
>> compositing, and then discarded, but that may well be less costly than my
>> (stupid, simple-minded, straightforward, unoptimized) algorith for
>> calculating the exact rect.
>>
>> We use extactRect in many places, though, and optimizing it would be a
>> great idea.
> But honestly, I don't think we can do better, except by caching it, but it
> wouldn't help in this situation. (I was thinking about real time updating 
> of
> the real bound, but it's not really possible and not sure if it would be
> faster).
>
> But for that specific use, I think that we can add a parameter to
> bltSelection : bool checkIfTotallyUnselected, default will be true, and 
> for
> the duplicate op, as we know that the test will be false, we can set it to
> false, if you see what I mean ?
>
> -- 
> --- Cyrille Berger ---
> _______________________________________________
> kimageshop mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
> 




More information about the kimageshop mailing list