core/color_strategy

[Boudewijn Rempt]

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.

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 
becoming memory-hungry. 

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
Type: application/pgp-signature
Size: 198 bytes
Desc: signature
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20031028/f1ff2b0e/attachment.bin