boud at valdyas.org
Tue Jul 6 08:39:56 CEST 2004
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
> > 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
> 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
> 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
Boudewijn Rempt | http://www.valdyas.org/fading/index.cgi
More information about the kimageshop