basegfx::BColor

[Armin Le Grand]

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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20171009/3657be71/attachment.html>