On October 28, 2003 03:22 pm, Boudewijn Rempt wrote:
> Hi,
>
> 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.


_______________________________________________
kimageshop mailing list
kimageshop@mail.kde.org
http://mail.kde.org/mailman/listinfo/kimageshop