Design of KisCurveIterator

[Bart Coppens]

A quick glance at it right now before I hop off to bed, I'll read it again 
tomorrow to see if I missed the point ;-)

On Sunday 28 May 2006 01:56, Cyrille Berger wrote:
> Hello,
> I want to introduce a new kind of iterator, those iterator would follow a
> line defined by a function (think of an iterator following a wave defined
> by cosinus for some deformation filter, or think about a distortion
> correction filter).
Sounds interesting indeed.

> KisCurveFunction is an interface which should be inherited to implement the
> function describing the curve. I am not quiet sure yet if it's best to use
> directly the function or its derivative, or both, but it would look like:
Whatfor exactly would you use the derivative in this case? Especially because 
since this is an R -> R^2 function which you're differentiating, do I fail to 
see the purpose of having it. Or perhaps it's too late for that at this point 
in the night to think about. Also, don't forget not all functions have 
derivatives at all points of their domain, so this might be a problem for 
some things if you're going for real genericity.
(Kind of PS: I suddenly realize you perhaps might need it to nicely determine 
the next value of t to use.)

> KisCurveFunction should be accessible by the at least the
> KisTiledCurveIterator, and plugins. That's why I was thinking to put in
I guess you meant to say 'put in sdk/'?

> The big question without answer yet is wheter the subsamplinging is handled
> by the iterator or by the user. For reading, it's pretty easy how to do it.
> But I am little bit skeptical for writing, in the use I have in mind I
> don't need writing, so maybe this iterator should be read only ?
Why not have bool useSubsampling(); void setUseSubsampling(bool); for the 
reading functions? I agree it's not really intuitive how to handle the write 
part, so leaving this out should be no problem.

> Bart asked me on irc why not use the allready available iterators ? Good
> question, but:
Reading the next part didn't really change my opinion, though ;-)

>  1) as CurveIterator needs subsampling, and need access to four pixel, so
> with current iterators I do fair that either by using four iterators or
> somehow hacking around to have one, we will have a serious performance
> problem (changing tile is very expensive, and I do think that there would
> be a problem when iterating close to the border of a tile)
Hum well, why not use the Rect iterator with this (2x2 rect). Seems perfectly 
suited towards this. Since you'd only need 4 pixels, I'd say manually copying 
3 of them to a temporary array won't be the end of the world, 
performance-wise.
A point of concern might be that, indeed, in the case where you'd move across 
tile borders, it the tile management might swap out the tile with the first 
pixel being read, and then swap it in again after ++iterator;, but since we 
use a First In-First Out swapping strategy, that's very very very unlikely 
(you'd need to have some really weird performance settings, and very bad 
luck).
Another point is the possibility of acquiring a lock to a tile, and then 
needing to re-acquire it each time your iterator iterates. Another idea might 
be to do some kind of cache-ahead in your iterator: make some estimate as to 
the area your iterator will be hovering over the next, say 20, pixels, and 
acquire a bounding box for that using a RectIterator internally.

>  2) current iterators' API does not allow to implement CurveIterator in an
> efficient and clean way, and transforming their API would, I think, damage
> their purpose. As clearly, the CurveIterator needs something close to
> random access in the image. I mean random path in the image.
Well, see, if going from one pixel to the next in a cure is pure random 
access, your derivative will be really wonky ;-)
Next, if it really is random, it even invalidates my previous possible speed 
issue (the one with re-acquiring the same tile multiple times consecutively). 
Furthermore, given my previous paragraph, I don't see the 
efficiency-cleanness issues at this time. (Rather, personally I might be 
inclined to believe that putting all kinds of iterator kinds into the tiles 
code is not really the cleanest thing to do.)

Anyway, at the moment I still think this kind of thing is too sophisticated 
and highlevel to directly delve into the tile manager code for this. (And 
this has become a longer reply than I planned at this time, damn you ;-))

Bart