Filter's changeRect() and merging problems

[Cyrille Berger]

On Saturday 22 August 2009, Dmitry Kazakov wrote:
> Hi all!
>
> I'm revising our merging strategy  at the moment. We have big problems
> with  it. I  want it  to take  into account  need rects  of adjustment
> layers.
>
> At  the   moment  i  have   problems  with  KisFilter::changedRect(rc)
> rect. Could someone  describe me what it is? Is  there any usecase for
> that?
Lets take the example of a translation filter, with a 1px distance.

When you filter (x,y), you need pixel (x-1,y-1) to compute the value of (x,y).

Now lets assume, the pixel (x,y) was changed while drawing, the question is to 
know which pixel of the output needs to be changed, in this case (x+1,y+1)

So for that filter KisFilter::changedRect(rc) return rc.translated(1,1); While 
KisFilter::neededRect(rc) return rc.translated(-1,-1);


> Actually,  i understand  that this  is  a rect  that adjustment  layer
> changed after applying on @rc  rect. But(!) how should update strategy
> treat this rect?  There are two possibilities:
>
> 1) Update  strategy should update  this _expanded_ rect on  all higher
> layers
>
> 2) Update strategy should NOT  pay any attention to this expanded rect
> and all higher layers should update requested rect only.

Lets take an example, here is the layer stack:

3) toplayerwithdrawing
2) filter layer, with a translation of ( x = 20px, y= 10px)
1) bottomlayerwithdrawing

Lets assume we are drawing on "layer 1", we dit a change on rect 
r1=(x=12,y=15,w,h).
This means, that for "layer 2", the rectangle that was changed is in reality 
"r2=(x=32,y=25,w,h)". And that you need to recompose that rectangle r2 with 
the content of "layer 3", while currently we always recompose r1.

I am not really sure where the problem needs to be solved, but I would look at 
setDirty, and when it goes up in the layer stack, it should probably called a 
function of KisNode (that doesn't exist) but that would return the changedRect 
in case of a filter, and the normal rect in other cased.


-- 
Cyrille Berger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20090824/49114679/attachment.htm