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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
--
--
ALG (PGP Key: EE1C 4B3F E751 D8BC C485 DEC1 3C59 F953 D81C F4A2)
_______________________________________________
LibreOffice mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
