diff options
author | Noel Grandin <noel.grandin@collabora.co.uk> | 2025-01-13 15:03:05 +0200 |
---|---|---|
committer | Noel Grandin <noel.grandin@collabora.co.uk> | 2025-01-14 15:47:13 +0100 |
commit | e0d4d178caff1414a9a21fa57f06bc8d4d2c389a (patch) | |
tree | 2ac5062c997ee9a3a29e61f1e1039595468117c8 /icon-themes/human/cmd/lc_interactivetransparence.png | |
parent | 3eaa35e8bacc19a85f5c9d907450846bfa8bffae (diff) |
It is pretty ugly bad on several levels.
Essentially what the currrent behaviour does is, if the fill color has an
transparency value, and draw some pixels, we just don't bother to write
anything to the color surface at all, we only write to the alpha surface.
(*) It is impossible to emulate efficiently when we switch to combined
color+alpha surfaces
(*) It works completely differently to how every other graphics API in the
world operates
(*) It makes no sense - it doesn't allow you to fill a shape with partially
transparent color pixels (because it just doesn't bother writing to the
color surface).
This behaviour dates back to "initial import", so sadly no reason why.
Noting that we are changing 3 things here:
(1) Setting a fill color with transparency will actually write to the color
surface.
(2) Previously, SetFillColor(COL_TRANSPARENCY) was the same as
SetFillColor(), now they mean different things
(3) SetFillColor(x) where x has tranparency will now actually affect the fill
color of the alpha layer.
(4) VirtualDevice::SetOutputSizePixel will now erase/fill the device with
data in cases where it previously would not (because previously the
fill was ignored when background == COL_TRANSPARENT)
Change-Id: I4c8b371a436a4d1ffc4344c7d6b21932d861397d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180184
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Diffstat (limited to 'icon-themes/human/cmd/lc_interactivetransparence.png')
0 files changed, 0 insertions, 0 deletions