https://bugs.documentfoundation.org/show_bug.cgi?id=167836
--- Comment #9 from Saburo <[email protected]> --- (In reply to Noel Grandin from comment #8) > I would rather know which commit caused this regression. Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e0d4d178caff1414a9a21fa57f06bc8d4d2c389a commit e0d4d178caff1414a9a21fa57f06bc8d4d2c389a author Noel Grandin <[email protected]> Mon Jan 13 15:03:05 2025 +0200 Change alpha behavour of OutputDevice::SetFillColor 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 -- You are receiving this mail because: You are the assignee for the bug.
