https://bugs.documentfoundation.org/show_bug.cgi?id=156629
Michael Weghorn <m.wegh...@posteo.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.documentfounda
| |tion.org/show_bug.cgi?id=15
| |5912
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
CC| |m.wegh...@posteo.de,
| |noelgran...@gmail.com,
| |plub...@neooffice.org,
| |tele...@surfxs.nl
--- Comment #1 from Michael Weghorn <m.wegh...@posteo.de> ---
Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: ed5d9496320d78032ab4a65fc5547aad069d19f2
CPU threads: 12; OS: Linux 6.4; UI render: default; VCL: gtk3
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded
Self-confirming, since Telesto also mentioned this in tdf#155912 comment 40.
This starts at
commit 81994cb2b8b32453a92bcb011830fcb884f22ff3
Author: Noel Grandin
Date: Fri Apr 16 20:33:10 2021 +0200
Convert internal vcl bitmap formats transparency->alpha (II)
(Second attempt at landing this)
Image formats and graphics APIs use alpha, not transparency,
so change our internal formats and data structures to work directly
with alpha, so we don't need to modify data before we push it to
graphics APIs.
Add a couple of new Color constants to make the intention
of the vcl code clearer.
Notes
(*) On macOS, tweaking the logic in CreateWithSalBitmapAndMask
to more accurately reflect the requirements of the
CGImageCreateWithMask function seems to fix some
tests.
(*) The vcl code does not properly support gradients
with transparency. So the previous code was wrong, and this
change is going to result in slightly different wrongness.
Change-Id: I9e21c2e98d88ecfdc5f75db13bd1ffff7c38db98
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114168
Tested-by: Jenkins
Reviewed-by: Patrick Luby
Reviewed-by: Noel Grandin
--
You are receiving this mail because:
You are the assignee for the bug.
