Design of KisCurveIterator

[Cyrille Berger]

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).

In the example I will used to explain myself I will take a CurveIterator 
following ( x=10*cos(t/10) y=10*sin(t/10) t >=0).

As those iterators follow a curve they will be never precisely on one pixel, 
and therefor would need to access four pixels, and subsample them. For 
instance, for t = 0, we have x= 10, y=0, it's precisely one pixel, but for 
t=10 we have x=5.4 y=8.4.

My design involves three classes (I won't speak about traits here, nor about 
the thin virtual layer of the other iterators, but curve would have one 
too)  : KisCurveFunction, KisCurveIteratorPixel (in core/ ) and 
KisTiledCurveIterator (in core/tilemanager)

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:

class KisCurveFunction {
    public:
        virtual KisPoint valueAt(int t) =0;
//	virtual KisPoint derivativeAt(int t) =0;
};

KisCurveFunction should be accessible by the at least the 
KisTiledCurveIterator, and plugins. That's why I was thinking to put in 

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 ?

KisTiledCurveIterator would manage the tiled (it has four tiles to manage).
KisCurveIteratorPixel is the core wrapper to hide the tiled manager, and would 
be in charge of subsampling.

Bart asked me on irc why not use the allready available iterators ? Good 
question, but:
 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)
 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.

-- 
--- Cyrille Berger ---