boud at valdyas.org
Tue Oct 28 21:22:16 CET 2003
Just updated and got the move to core/color_strategy -- now I see what you
meant by flyweights. I thought you wanted a flyweight object for every color,
so pixels can point to those colors, or something like that. Because I
thought that the essence of flyweight was that there were many of them, and I
guess we'll never have more than a handful of color models.
Anyway -- this is very nice. I've made a start adding composite methods to
every the color models. Is that okay, or were you working on that?
I'm currently having a signature like:
virtual void composite(QUANTUM *src,
QUANTUM *dst, Q_INT32 opacity, CompositeOp op);
Where src and dst point to just enough bytes to define a pixel.
I've looked at putting a koColor in and getting a new koColor back -- which
somehow seems neater to me, more encapsulated. But that would be more costly,
since every pixel needs to be converted to a koColor then, and even an array
of flyweights for every color in the picture wouldn't help Krita from
And I've played with passing pointers to the entire scanline, or all the bytes
in the tile, together with the length of that block, but while that would be
very efficient for copy operations, I thought it rather ugly in design, and
anyway, optimisations can always be done later.
Boudewijn Rempt | http://www.valdyas.org/index2.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20031028/f1ff2b0e/attachment.bin
More information about the kimageshop