Description: Character highlighting: custom color color picker doesn't look properly with skia raster on macOS Steps to Reproduce: 1. Open Writer 2. Click expand button for character highlighting 3. More colors Actual Results: See screenshot Expected Results: Normal look Reproducible: Always User Profile Reset: No Additional Info: Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: fbf739198aa7f02975d531521c6525073783c7f1 CPU threads: 8; OS: Mac OS X 12.2.1; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Created attachment 179530 [details] Screenshot
Confirmed using LO 7.4 daily build from 06-04 on macOS, with Skia/Raster.
What does 'doesn't look properly' mean?
(In reply to Luboš Luňák from comment #3) > What does 'doesn't look properly' mean? As can be seen in the screenshot, the colors are incorrect.
Happens with Skia/Metal as well. And only the large color area and the color band has wrong color, the small color preview in the bottom left corner and the actual color that is used in the end are both correct.
Dear Telesto, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still present with Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: d2eab48f697a1e6097778158f623f11306ac7a3d CPU threads: 8; OS: macOS 14.3; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded not present with non-skia rendering Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: d2eab48f697a1e6097778158f623f11306ac7a3d CPU threads: 8; OS: macOS 14.3; UI render: default; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
@Patrick You might be interested in this one
(In reply to Telesto from comment #8) > @Patrick > You might be interested in this one Like you, I see the same color distortion with both Skia/Metal and Skia/Raster but not with Skia disabled. To me, it looks as if all of the colors have "whitened" or all of the colors are semi-transparent against a white background when using either Skia setting. When I get some time, I will see if I can find the code that draws the colors in this dialog.
So I've narrowed down where the bug is occurring and it is in SkiaSalGraphicsImpl::drawPixel(). Still need to do more debugging. One question: does this bug occur with Skia/Vulkan and/or Skia/Raster on Windows and/or Linux? Or is this just a Skia on macOS bug?
(In reply to Patrick Luby (volunteer) from comment #10) > One question: does this bug occur with Skia/Vulkan and/or Skia/Raster on > Windows and/or Linux? Or is this just a Skia on macOS bug? I submitted a fix in the following patch. At least on macOS, this bug only occurs with a Retina display. If I force non-Retina resolution by setting my Terminal enviroment variables to SAL_FORCE_HIDPI_SCALING=1, the bug does not occur. So, I think that this bug only occurs when drawing a pixel with scaling: https://gerrit.libreoffice.org/c/core/+/168973
@V Stuart Foote From comment 10: One question: does this bug occur with Skia/Vulkan and/or Skia/Raster on Windows and/or Linux? Or is this just a Skia on macOS bug? Would you mind to test this on Windows with a HiDPI screen?
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a4488013ee6c87a97501b620dbbf56622fb70246 tdf#148569 set extra drawing constraints when scaling It will be available in 25.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.
I have committed a fix this bug. The fix should be in tomorrow's (18 June 2024) nightly master builds: https://dev-builds.libreoffice.org/daily/master/current.html Note for macOS testers: the nightly master builds install in /Applications/LibreOfficeDev.app. These builds are not codesigned like regular LibreOffice releases so you will need to execute the following Terminal command after installation but before you launch /Applications/LibreOfficeDev: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/577f68bc29273c66466dbde5128fec66b01868b4 tdf#148569 set extra drawing constraints when scaling It will be available in 24.8.0.0.beta2. 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.
(In reply to Telesto from comment #12) > @V Stuart Foote > From comment 10: One question: does this bug occur with Skia/Vulkan and/or > Skia/Raster on Windows and/or Linux? Or is this just a Skia on macOS bug? > > Would you mind to test this on Windows with a HiDPI screen? On Win10 with 4K monitor, neither Skia Vulkan nor Skia raster rendering causes that distortion in the 2D color chart for the 'Pick a color' dialog, colors are fully saturated and follow the Hue of the picker. No apparent issue as the graphic is scaled. Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 6d39b1a6068bbbd5ca4947f668f989dbfb73342d CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/f6e4fa4dab3d31ac355aa796f0325f94e7069f40 tdf#148569 set extra drawing constraints when scaling It will be available in 24.2.5. 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.
I tested DOCX with lot of pages and images that loads slowly in newer versions, due to multile perf regressions. In 24.8+ this commit caused a fileopen slowndown from 4:50 to 5:40. DOCX is private and I cannot open a ticket with it. Rather, I ask you to reconsider this commit.
Note: test and slowdown are in Linux GTK3.
For the moment, please revert 24.2.
(In reply to Timur from comment #20) > For the moment, please revert 24.2. How about I just limit the change to macOS only? The macOS Retina display of "1 pixel is backed by 4 pixels" appears to be unique to macOS so I think my fix is overkill for Windows and Linux. I can get patches in Gerrit today back from master back to 24.2 later today.
Thanks. Please do. It would be good to find large DOCX with lot of images in the existing tickets to retest, but I could not find it.
(In reply to Timur from comment #22) > Thanks. Please do. It would be good to find large DOCX with lot of images in > the existing tickets to retest, but I could not find it. OK. I have submitted the following patch that limits the fix for this bug to only macOS with a Retina display. If you see anything that needs changing for Linux and/or Windows, please let me know and I can update the patch this evening: https://gerrit.libreoffice.org/c/core/+/169475
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ef2c71d3a78904a917b3001f6ec043d00fc3f71f Related tdf#148569: do not apply macOS fix to non-macOS platforms It will be available in 25.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.
So I have committed a patch that limits the fix for this bug to only macOS. Can anyone confirm that this bug does *not* occur on Linux and/or Windows in tomorrow's (26 June 2024) nightly master build? On macOS, this bug only occurred with Retina (2x resolution) displays so I am not sure what the equivalent Linux and Windows display settings are. You may need to run LibreOfficeDev from the command line with the following environment variable set to emulate what I see on macOS: export SAL_FORCE_HIDPI_SCALING=2
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/4982d78f887440cbb12aec512a757dd7d3a75f43 Related tdf#148569: do not apply macOS fix to non-macOS platforms It will be available in 24.2.5. 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.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/16be4df75b23ec68c758e203a08af0f9486ebafb Related tdf#148569: do not apply macOS fix to non-macOS platforms It will be available in 24.8.0.0.beta2. 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.