Re: basegfx::BColor

Hi Chris,

please don't. Have you seen that it's derived from B3DTuple and thus is 
using three doubles? This makes it way bigger than the current one. It 
is more a interface class for ghaving the color ranges in abstract 
[0.0..1.0] range, so independnent from a device's color resolution. Is 
is in that form not seiously usable e.g. for spawnig Bitmaps.

For adding alpha it would be better to derive a class adding it, but was 
not yet needed -see e.g. drawinglayer::attribute::LineAttribute and others.

It is *not* always feasible to have RGB and A together - basic 
Canvas(es) never have Alpha (seen as last target for paint), 
Bitmap/in-between targets have.

Just my 2ct,
Armin


Am 08.10.2017 um 14:22 schrieb Chris Sherlock:
> Just a quick query: is there any reason why basegfx::BColor doesn’t 
> store the alpha value?
>
> I was thinking it would be great to migrate from tools::Color to 
> basegfx::BColor, but I genuinely don’t think this is really possible 
> without storing the alpha channel.
>
> Also, I noticed a decent gerrit patch by Noel that removes yet another 
> variant of Color in cppcanvas:
>
> https://gerrit.libreoffice.org/#/c/43240/
>
> It would be great to have literally only one implementation of Color :-)
>
> Also, I proposed a Color modifier earlier to do alpha blending:
>
> https://gerrit.libreoffice.org/#/c/43223/
>
> Feedback is that BColorModifer_interpolate can do this already, so 
> it’s not like we don’t have the infrastructure to do this...
>
> Thoughts?
>
> Chris
>
> Sent from my iPhone
>
>
> _______________________________________________
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice

--
--
ALG (PGP Key: EE1C 4B3F E751 D8BC C485 DEC1 3C59 F953 D81C F4A2)