summaryrefslogtreecommitdiff
path: root/icon-themes/karasa_jaga_svg/fpicker/res
diff options
context:
space:
mode:
authorNoel Grandin <noel.grandin@collabora.co.uk>2025-01-13 15:03:05 +0200
committerNoel Grandin <noel.grandin@collabora.co.uk>2025-01-14 15:47:13 +0100
commite0d4d178caff1414a9a21fa57f06bc8d4d2c389a (patch)
tree2ac5062c997ee9a3a29e61f1e1039595468117c8 /icon-themes/karasa_jaga_svg/fpicker/res
parent3eaa35e8bacc19a85f5c9d907450846bfa8bffae (diff)
Change alpha behavour of OutputDevice::SetFillColor HEADmaster
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/karasa_jaga_svg/fpicker/res')
0 files changed, 0 insertions, 0 deletions