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

List:       kde-kimageshop
Subject:    core/color_strategy
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2003-10-28 20:22:16
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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

[Attachment #5 (application/pgp-signature)]

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


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