[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    Re: Back
From:       "Casper Boemann" <cbr () boemann ! dk>
Date:       2004-07-26 9:02:38
Message-ID: 025d01c472ef$65a5c750$cdc19109 () IBMfk13045
[Download RAW message or body]

> Frankly, by this time I'm getting a bit exhausted and don't know anymore
which
> 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
proliferation
> of QUANTUM types -- we will at least have Q_UINT8, Q_UINT32, float and
double
> 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,
with
> 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
Casper

_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]