Yet another bug. This time filters vs selections
Dmitry Kazakov
dimula73 at gmail.com
Mon Sep 14 10:48:51 CEST 2009
On Mon, Sep 14, 2009 at 12:19 PM, Cyrille Berger <cberger at cberger.net>wrote:
> On Sunday 13 September 2009, Dmitry Kazakov wrote:
> > Btw, Blur filter doen NOT pay any attention to selections. And i do not
> > know the way how can it do that. =(
> it's probably just a matter to give the iterrators the selection object.
>
It won't solve the problem of semi-selected pixels (pixels with alpha~128).
Such pixels should be filtered with cs->applyAlphaU8Mask() separately. I
think it'll be quite complex solution for blur filter.
Atm, i insist on using bitBlt after the filtering. This will make filter
creation much simplier, especially for filters that are quite complex
themselves (like convolution). My tests show the following overhead:
when 28% of the canvas is deselected we get only 2% overhead
when 53% of the canvas is deselected we get only 13% overhead
(i got these numbers with brightness/contrast filter)
More that that, there are some ways to optimize bitBlt in feature, like
create a loop that checks upcoming pixels for isSelected().
PS:
Btw, Qt uses PrecomputedARGB for some complex operations. Can't we use
something like that for selections?
--
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20090914/66884357/attachment.htm
More information about the kimageshop
mailing list