Created attachment 203172 [details] Chart stackedb_svg Inkscape 1.4.2 150dpi +++ This bug was initially created as a clone of Bug #149592 +++ Attachment 126372 [details] from the bug 101083 is not displayed correctly. 1) Open attachment 126372 [details]. Result: Text, lines, colors and positions are different from Inkscape or web browsers.
Created attachment 203173 [details] Firefox 143
Created attachment 203174 [details] Chrome 141
Created attachment 203175 [details] Edge 141
Created attachment 203176 [details] LO24.2.7.2
Created attachment 203177 [details] LO25.8.1.1
Created attachment 203178 [details] LO26.2dev20250912
Created attachment 203179 [details] LO26.2dev20251005 Mentioned versions: Version: 24.2.7.2 (X86_64) / LibreOffice Community Build ID: ee3885777aa7032db5a9b65deec9457448a91162 CPU threads: 16; OS: Windows 10.0 Build 26100; UI render: Skia/Raster; VCL: win Locale: pl-PL (pl_PL); UI: en-US Calc: CL threaded Version: 25.8.1.1 (X86_64) Build ID: 54047653041915e595ad4e45cccea684809c77b5 CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: pl-PL (pl_PL); UI: en-US Calc: CL threaded dev 2025-09-12 Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b33cc5a7388c1739ff4a02a84751800f3e3086ce CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: pl-PL (pl_PL); UI: en-US Calc: CL threaded dev 2025-10-05 Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: c01e50ce848eb175813c27679d6c52056ea67625 CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: pl-PL (pl_PL); UI: en-US Calc: CL threaded
Created attachment 203180 [details] Original SVG - cropped
So this is specifically about the change seen in the bars of the chart. (In reply to Piotr Osada from comment #5) > Created attachment 203177 [details] > LO25.8.1.1 This change happened with commit e0d4d178caff1414a9a21fa57f06bc8d4d2c389a Change alpha behavour of OutputDevice::SetFillColor (In reply to Piotr Osada from comment #6) > Created attachment 203178 [details] > LO26.2dev20250912 What I see doesn't match the screenshot exactly (I have coloured borders around the bottom three blocks), but the change happened with commit 232d7631e86bf5d0a21aca899f6a0239aa9486be BitmapEx->Bitmap in MetaBmpExScalePartAction
(In reply to Buovjaga from comment #9) > (In reply to Piotr Osada from comment #6) > > Created attachment 203178 [details] > > LO26.2dev20250912 > > What I see doesn't match the screenshot exactly (I have coloured borders > around the bottom three blocks), but the change happened with commit > 232d7631e86bf5d0a21aca899f6a0239aa9486be > BitmapEx->Bitmap in MetaBmpExScalePartAction Are you sure about this bisect? I bisected using source (on Windows) and I get: commit f109008fea11d0b837778c2d2ed77e15497fe3df Author: Noel Grandin <noelgrandin@gmail.com> Date: Tue Sep 9 14:29:00 2025 +0200 tdf#149592 Importing SVG with too small scaling causes bad performance But this bug is manifesting differently on differnt platforms and backends, so who knows...
(In reply to Noel Grandin from comment #10) > (In reply to Buovjaga from comment #9) > > (In reply to Piotr Osada from comment #6) > > > Created attachment 203178 [details] > > > LO26.2dev20250912 > > > > What I see doesn't match the screenshot exactly (I have coloured borders > > around the bottom three blocks), but the change happened with commit > > 232d7631e86bf5d0a21aca899f6a0239aa9486be > > BitmapEx->Bitmap in MetaBmpExScalePartAction > > Are you sure about this bisect? I bisected using source (on Windows) and I > get: > > commit f109008fea11d0b837778c2d2ed77e15497fe3df > Author: Noel Grandin <noelgrandin@gmail.com> > Date: Tue Sep 9 14:29:00 2025 +0200 > tdf#149592 Importing SVG with too small scaling causes bad performance > > But this bug is manifesting differently on differnt platforms and backends, > so who knows... Ah, looks like there has been an intermittent different state. I checked the commit you referenced and the previous state and indeed the previous state has different colours. However, the black is also seen in the commit I mentioned. If you have the Windows 26.2 bibisect repo, the binary commit is 944116d0dcadb08d97a98ce7ebc0ac91f42e2258
What even is the "right" rendering of this SVG, since Chrome/Firefox/Inkscape disagree on what colors should be inside the bars?
(In reply to Noel Grandin from comment #12) > What even is the "right" rendering of this SVG, since > Chrome/Firefox/Inkscape disagree on what colors should be inside the bars? Ignoring the exact shades, this matches what is seen in Inkscape and Chrome-based browsers and makes sense presentationwise: (In reply to Piotr Osada from comment #5) > Created attachment 203177 [details] > LO25.8.1.1 Firefox for some reason doesn't want to fill the middle blocks, just like we did in 24.2.
Since I am unlikely to fix this, here are my notes for the next person: There are several different things going wrong here, from most important to least: (*) something is going weird in how mapmodes/transformations are being applied in VclPixelProcessor2D::processPatternFillPrimitive2D and in impBufferDevice. Which means that the pixels are not ending up in the right spot. I cannot follow this logic at all. (*) The buffering/caching in PatternFillPrimitive2D is getting out of sync sometimes (but only sometimes). Depends on timing. When it does we get black rectangles in the output. This is part of what makes this so hard to bisect. Random changes in other code can change the timing and trigger this. (*) The Bitmap->BitmapEx changes are making small, but noticeable changes to the colors, due to changes in how often we combine and split alpha and color.
Also, (*) The way that impBufferDevice::impBufferDevice calculates the maskrect is different from how the calling code calculates maskrect which leads to subtle off-by-one (but again, only sometimes)
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/99d7bbf367eeb85055853d0d03ec46b2d6bbebe3 tdf#168730 fix DrawRect with alpha It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/01eb49583d98810a5e05f53f39393922818b91a5 Revert "tdf#168730 fix DrawRect with alpha" It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f5b8ec6b3fbc9a48bded4e621cc1bf3a8093f824 tdf#168730 impBufferDevice and caller should have the same mask rect It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 203487 [details] LO26.2dev20251022 bar colors fix Noel Grandin fix verification commit f5b8ec6b3fbc9a48bded4e621cc1bf3a8093f824 tdf#168730 impBufferDevice and caller should have the same mask rect Fixed: bar colors are displayed. Still bug: missarranged text With recent dev version, the following colors are displayed: HEX, rgb, hsv Bottom black bar (1st): line: #000000 fill: #FFFFFF 2nd red: line: #FF0000 fill: #FFF7F7 RGB: 255, 247, 247 HSV: 0, 3, 100 3rd blue: line: #0000FF fill: #F7F7FF RGB: 247, 247, 255 HSV: 240, 3, 100 4th purple: line: #7221BC fill: #7221BC RGB: 114, 33, 188 HSV: 271, 82, 74 https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb103-1-TDF/2025-10-22_15.51.57/ Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 620(Build:0) CPU threads: 16; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Vulkan; VCL: win Locale: pl-PL (pl_PL); UI: en-US Calc: CL threaded