always an alpha channel
boud at valdyas.org
Wed Sep 15 15:59:53 CEST 2004
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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20040915/1e981071/attachment.pgp
More information about the kimageshop