always an alpha channel

[Boudewijn Rempt]

On Wednesday 15 September 2004 15:30, Casper Boemann wrote:

>
> Case 1 problems might be overcome, if we think of a "normal layer" as a
> "color layer" and an "alpha layer" always combined. The "normal layer"
> would then have the responsibillity of combining the two. But what happens
> when we use paintdevices that are not layers - wouldn't we still want alpha
> for those?

Of course. Otherwise you won't be able to do antialiased brushes. Before 
painting a brush stroke, the brush mask is first converted to a paint device.

>
> My suggestion would be more in the like of a RGB colorstrategy, a RGBA
> colorstrategy, a RAGABA colorstrategy and so fourth with CMYK, CMYKA etc.
> To avoid code duplication we could have an AlphaColorstrategyTrait and let
> RGBA inherit from both RGBColorStrategy and AlphaColorstrateyTrait. The
> trait could be reused for CMYK with alpha.

Yes, that could be the way to go, I think. But the current API is confusing
with its myriad ways of discovering whether there's an alpha channel, and no 
way to add one that's missing...

On the other hand, once onvererting between RGB and RGBA would become 
possible, having an in-band alpha would slow things down. The advantage of 
using a separate alpha 'layer' that's always associated with a paint device 
is that it becomes really easy to add or remove an alpha channel.

Oh, well -- I'll add some templates first, fix the selections workflow & 
paste/past into and move, and look into the weird scaling artefacts for 
images that are partly obscured by the UI. And there are composition 
artefacts that show up in the selection code.

-- 
Boudewijn Rempt | "Geef mij maar zuurtjes."
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/20040915/1e981071/attachment.pgp