branches/koffice/1.6/koffice/krita/plugins/filters

[Bart Coppens]

On Thursday 07 September 2006 13:33, Cyrille Berger wrote:
> convolution behave as wave, I think we should find a solution where the
> whole paintdevice is given to the filter, even if the work of the filter is
> limited to a QRect.
In a way you're right. Let me look into this.

> well at least for somerandom it's still possible to have a deterministic
> randomness wether it depends of X,Y or not.
Hmmmm? If it doesn't depend (explicitly or implicitly) on the coordinates, how 
will you make it deterministic?

> That's an other question, do we still need to have src and dst seperated ?
> The more I think of adjustement layer, the more I think the answer is yes,
> CoW tiles isn't enought. And we need to fix everywhere code wich assumes
> src == dst like convolution.
Well, as far as I remember, the idea has always been to force dst == src, but 
I can't remember the reasons for it. I'm sure there were good reasons, 
perhaps speed and/or complexity issues? With dst==src, you can use a rect 
iterator as a source, and a rect iterator as destination, whereas with 
src!=dst, you'll need 2 hline iterators and a while loop, which is just 
slightly more complex and probably slightly slower? Just guessing, though. 
But yeah, with adjustment layers, dst!=src makes sense.

> Sorry I meant autocontrast ;)
Ah ok :)

> And I had rather see only one type of 
> implementation, I don't see the need to solve twice this issue. And
> actually I think solution 2 is the best.
It is, but I'm not sure how feasible it is.

> > Anyway, bottomline of how I see it, in 2.0 we should be able to use 1a
> > and 1b filters, some of 2 and 3, decided on a case-by-case review of how
> > the filter performs. But remind that all of the cases need extra code.
>
> if it was easy, it wouldn't be interresting ;)
So true :P

Bart