Iterator requirements

[Boudewijn Rempt]

On Tuesday 06 July 2004 00:49, Cyrille Berger wrote:
> > * Iterators
> >
> > 	Iterators offer random and linear read/write access to channels, pixels
> > and 2 dimensional arrays of pixels.
> >
> >
> > 	Iterators return pixel data as a vector/array (whatever, but preferably
> > not a pointer to a amorphous chunk of bytes*) of bytes which can be
> > interpreted by the colour strategy as a colour.
> > 	Iterators can skip pixels according to selection status, with a degree
> > of fuzziness.
>
> I have already made a change (not commited yet), that will help : I have
> add an "=" operator that will make the convert to QUANTUM* operator
> deprecated.
>
> > 	Iterators and single pixel values are passed to the colour strategies
> > for colour model specific handling.
>
> I was planning to work on that specific part during this week. 

Good -- the idea is to get rid of the various tileBlt methods in KisPainter,
and pass the iterator for the rect that is being composed to the colour 
strategy -- this probably means that we also need an iterator that takes a 
rect as constructor param and then iterators over the pixels inside that 
rect.

> And I was 
> planning to implement a second type of iterrator that will return a class
> representing a pixel.

I don't care much one way or another (I slightly prefer having a class, but 
that's my Java background speaking), so that's something you and Casper must 
discuss and decide.

>
> > 	Colour strategies can render their pixels to display RGB format (i.e. a
> >    QImage).
>
> or better a QPixmap.

A QImage has some advantages because it is used by a lot of other KDE 
libraries, making integration easier. There's nothing that will prevent us 
from offering both, though. I already did some code to produce QImages, and 
it's easy to go from QImage to QPixmap -- in fact, you need to have a QImage 
first anyway.

> When writting the grayscale strategy, I noticed that there was a lot of
> unnecessary call to the render function of the strategies, I wonder if it
> wouldn't be faster to have a tile manager of pixmap. This way, we only have
> to compute the transformation if the tile has been changed.

Is there actually much unnecessary work done? I thought only the parts changed 
were re-rendered?

-- 
Boudewijn Rempt | http://www.valdyas.org/fading/index.cgi