Casper Boemann cbr at
Mon Jul 26 11:02:38 CEST 2004

> Frankly, by this time I'm getting a bit exhausted and don't know anymore
> I would prefer -- there's a lot to be said for the passing a pointer to a
> chunk of memory the size of a pixel to the color strategy, where it is
> interpreted, but KisPixelRepresentation might be fine, too
I must be very carful on what I say now, because I don't wan't you to think
that I approve of something that I don't, but here goes: Actually I don't
*fundamentally* mind creating a KisPixelRepresentation class with a pointer
to the data. I don't think there is any point in it as it involves creating
the class and copying data (yet it's only a pointer but still 4 bytes each
time, and we are talking millions of times per second) several times. But
that is only performance loss (for no good reason).

What I *fundamentally* don't like is the exposure of the channel data to
anyone but the colorstrategy.

 -- if you have a
> clear idea on how to proceed when we get to the complications of colour
> models with channels that are not all of an equal size, and the
> of QUANTUM types -- we will at least have Q_UINT8, Q_UINT32, float and
> for QUANTUMs after the first alpha.

Yes if anyone can explain how this should be accomplished, with the QUANTUMS
exposed I'm all ears.

> * Iterators should take a paint device, not a tile manager in their
> constructor. I want tile manager to be more private to the paint device,
> iterator being a friend or something to the paint device, so it can get at
> it. I'd just as soon never have anyone building an image manipulation
> algorithm extract the tile manager.

Which is why a factory method pattern should be used. Iterators *should*
take tile manager as argument for the constructor, but users should never
call the constructor. They should call paintdevice->getXXXIterator() which
*doesn't* take tilemanager as an argument.

> * I'd like to have a richer set of iterators: over rects, over tiles (for
> speed), and so on. Lines/pixel are okay.

Yes, by the way I think that a HLine and VLine iterator (actually special
cases rects, only 1 pixel high/wide respectively) could be a nice
replacement for lines/pixel. That way you could have a VLine iterator simply
acting as a "lineiterator". For each iteration you create a HLine iterator
to do the actual pixel iterations. The difference to the line/pixel concept
of today is that all iterators are conceptually the same. You just combine
them to get the effect you had before.

best regards

More information about the kimageshop mailing list