Blend modes

[Boudewijn Rempt]

On Thursday 30 June 2005 12:56, Casper Boemann wrote:

> During the development phase bloating the colorstrategies with too many
> blend modes only creates more work for us.

How much of a problem would that be -- I mean, every colorspace already has a 
different set of blend modes. Over, copy & erase are mandatory, but the set 
of other operators is freely extensible. If I add xor to w&s, then there's no 
reason for any other color model to support xor, for instance.

The real problem is with the functions that do calculations on pixels. If an 
abstract function is added to KisStrategyColorSpace, then all colorspaces 
have to add that function. That hurts development, both for you, when you're 
adding new functionality, and for me, when I'm working on W&S, or for Cyrille 
when he tries to keep grayscale up to date.

> I was thinking that perhabs we should have sub-maintainers of the
> colormodels. That way the sub-maintainer has the responsibility to always
> keep the colormodel up to date.
>
> And when one updates say the rgb model all one had to do was disable the
> other models from the makefile. It would then be the responsibility of the
> sub-maintainer to bring them back in.

I think we had maybe take another route: always add a default implementation 
that converts the colormodel to 8-bit/channel rgba and use that 
implementation if the actual color strategy doesn't implement it already. 
That way, all models are always up to date. 

Combined with a supportedOps method like the userVisiblecompositeOps function, 
we could implement in filters and so a warning if the user attempts to use 
functionality that will entail a lossy conversion, but it will not disable 
the functionality.

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20050630/86470c49/attachment.pgp