Yet another bug. This time filters vs selections

Dmitry Kazakov dimula73 at gmail.com
Thu Sep 10 18:55:46 CEST 2009


On Thu, Sep 10, 2009 at 12:18 PM, Cyrille Berger <cberger at cberger.net>wrote:

> On Wednesday 09 September 2009, Dmitry Kazakov wrote:
> > > to use such a solution for Shiva based filters, since OpenShiva doesn't
> > > know anything about masks and selections.
> >
> > I don't know how to make a benchmark of that, i guess, it would be
> > interesting to look at. We could test for the cold-cache problem at
> least.
> > (We could assume that big holes in a selection are quite rare and not
> very
> > important).
> To benchmark that, since currently it doesn't work, it's quiet easy to test
> the speed of method 2.
>
>
> You just have to make something like:
>
>
> * KisPaintDevice tmp;
> * filter->process(KisProcessInfo(src, src.origin() ), KisProcessInfo(tmp,
> QPoint(0,0), selection()), size);
> * then apply the mask on dst
>
>
> And see the overhead of applying the mask. It's still worth to pass the
> selection, so that we don't compute pixel value when the pixel is
> unselected.
>

Yes, it's not so good to filter unneeded areas, but iterating pixel by pixel
can create even bigger overhead due to cache footprint
 I'll try to make some tests now.



> Thinking about that, the highest cost will be the creation of tiles for the
> tmp KisPaintDevice
>

It can be smoothed a bit by a new tile3 engine with it's pooler and COW.


> and the need to iterate twice.
>

That is worse. But i'll take a try.




-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20090910/40e3a64b/attachment.htm 


More information about the kimageshop mailing list