freak at codepimps.org
Tue Oct 28 16:52:56 CET 2003
On October 28, 2003 03:22 pm, Boudewijn Rempt wrote:
> 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.
You will when we have premultiplied, they will hold a vector containing all
the pixels already in that specific alpha value.
> 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 still thinking about to implement
> I'm currently having a signature like:
> virtual void composite(QUANTUM *src,
> QUANTUM *dst, Q_INT32 opacity, CompositeOp op);
Probably this signature tho
virtual void composite(QUANTUM *dst, QUANTUM *src, Q_INT32 opacity,
CompositeOp op) const = 0;
Dst and src we're inverted to more closely match what is in krita already and
more closely follow the ANSI C mem* routines.
> 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 becoming memory-hungry.
Yes, it would, for only 8 bit channels, it's only 65000 values, but I'm afraid
I don't really understand what you are saying to me here tho.
More information about the kimageshop