I created this issue to provide a place to attach screen snapshots and/or documents related to the following Gerrit change: https://gerrit.libreoffice.org/c/core/+/114168
Created attachment 187972 [details] Sample file with transparent gradient overlapping text As of patch set 80, when Skia is disabled and the document is running in a slideshow, a white rectangle will be drawn underneath the transparent gradient, obscuring the text that the gradient overlaps. I have only confirmed this behavior on macOS. Also, when Skia is enabled, no white rectangle is drawn.
Created attachment 187973 [details] Screen snapshot of slideshow rendering problem Screen snapshot of slideshow rendering problem on macOS. Note that the "Blah" at the top edge of the gradient is partially drawn over by a white rectangle equal to the bounds of the gradient. Version: 24.2.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 022afc24d2e6ad74b26c905abbe6a42816d9a99e CPU threads: 8; OS: Mac OS X 12.6.6; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Setting the status to NEW: developer notes
Created attachment 188073 [details] Sample file with multiple overlapping transparent gradients
Created attachment 188074 [details] Screen snapshot of rendering multiple overlapping transient gradients during slideshow
Update: as of patch set 84 in the following Gerrit change, rendering of attachment https://bugs.documentfoundation.org/attachment.cgi?id=187972 now works properly. However, at least on macOS, having overlapping multiple transparent gradients (see attachment https://bugs.documentfoundation.org/attachment.cgi?id=188073) still renders a semi-transparent white background for all but the bottom-most gradient. This happens with Skia/Metal, Skia/Raster, and Skia disabled.
Created attachment 188084 [details] Sample file with overlapping, multi-colored transparent gradients
Created attachment 188091 [details] Exported PDF with Skia/Metal of overlapping, multi-colored transparent gradients This PDF shows that when Skia is enabled, transparent gradients aren't drawn when exporting a document to PDF. Note: there are no problems exporting the same document to PDF when Skia is disabled,
Created attachment 188092 [details] Sample file that contains a .png image with transparent pixels
Created attachment 188093 [details] Exported PDF of image with transparent pixels This PDF shows that the mask is rendered into of the image with transparent pixels when exporting to PDF. This occurs with either Skia enabled or disabled.
Update: as of patch set 89 in the following Gerrit change, transparent gradients and images with transparent pixels now render correctly when rendered in a document window, in a slideshow window, or to the printer on macOS. What still remains to be fixed is exporting both types of semi-transparent objects to PDF. I have been using the following attachments to debug: https://bugs.documentfoundation.org/attachment.cgi?id=188084 https://bugs.documentfoundation.org/attachment.cgi?id=188092 Exporting to PDF results in the following PDF files on macOS: https://bugs.documentfoundation.org/attachment.cgi?id=188091 https://bugs.documentfoundation.org/attachment.cgi?id=188093
Created attachment 188131 [details] .svg with transparent pixels and with 50% transparency applied to the whole image With patch set 92, LibreOffice will crash when running a slideshow or printing with Skia/Metal or Skia/Raster on macOS.
Created attachment 188132 [details] .svg extraneous draw artifacts In the attached screen snapshot, there is an extra white polygon that is not normally drawn in either LibreOffice 7.5.4 or in today's nightly master build. So most likely somewhere in the following Gerrit change has introduced this bug: https://gerrit.libreoffice.org/c/core/+/114168
Created attachment 188141 [details] Debug patch for master that prints the initial color of a VirtualDevice's alpha mask after being resized
Created attachment 188163 [details] Debug patch that removes all about dialog, slideshow, and export as PDF alpha mask hacks
Noting that the svg-odp attachment has very weird behaviour even without the transparency->alpha patch. On Windows it either freezes or crashes, so it appears to be hitting some paths that skia does not like.
(In reply to Noel Grandin from comment #16) > Noting that the svg-odp attachment has very weird behaviour even without the > transparency->alpha patch. On Windows it either freezes or crashes, so it > appears to be hitting some paths that skia does not like. I am also seeing a crash when using Skia/Metal. But, with Skia/Raster, I hit an assert very quickly before crashing at vcl/source/outdev/bitmap.cxx:361. On my machine, both of two "is empty" conditions are false i.e. there is some non-empty intersection rectangle for both conditions.
(In reply to Patrick Luby from comment #17) > I am also seeing a crash when using Skia/Metal. But, with Skia/Raster, I hit > an assert very quickly before crashing at vcl/source/outdev/bitmap.cxx:361. > On my machine, both of two "is empty" conditions are false i.e. there is > some non-empty intersection rectangle for both conditions. I forgot to say that this crash happens when running the LibreOffice logo .svg in a slideshow.
(In reply to Patrick Luby from comment #18) > I forgot to say that this crash happens when running the LibreOffice logo > .svg in a slideshow. Interestingly, the latest nightly master build doesn't crash in this case with Skia/Metal. Instead, it silently fails over to Skia/Raster after a few seconds and the image displays in a slideshow window on macOS. In contrast, with the Gerrit patch set 93 with Skia/Metal, it crashes when it tries to fail over to Skia/Raster. Restarting with Skia Raster leads to hitting the vcl/source/outdev/bitmap.cxx:361 assert.
Created attachment 188222 [details] Sample of LibreOffice just before crash When running a slideshow with https://bugs.documentfoundation.org/attachment.cgi?id=188131 and Skia/Metal (maybe Skia/Vulcan?) is enabled, LibreOffice will hang for several seconds before crashing.
(In reply to Noel Grandin from comment #16) > Noting that the svg-odp attachment has very weird behaviour even without the > transparency->alpha patch. On Windows it either freezes or crashes, so it > appears to be hitting some paths that skia does not like. So I have found the cause of the crash when running https://bugs.documentfoundation.org/attachment.cgi?id=188131 in a slideshow with Skia/Master. It is crashing in surface->getCanvas()->drawImageRect() in vcl/skia/salbmp.cxx:942. I have attached a sample of the LibreOffice process while it is in the above function just before the process crashes.
Created attachment 188233 [details] Screen snapshot of LibreOffice logo in slideshow with Skia/Raster enabled This screen snapshot was taken while running https://bugs.documentfoundation.org/attachment.cgi?id=188131 in a slideshow with Skia/Raster enabled on macOS with patch set 102.
After doing several time profiles with the Instruments application on macOS, I think that the crash when running in a slideshow with Skia/Metal with https://bugs.documentfoundation.org/attachment.cgi?id=188131 is due to the following Skia performance bug: https://bugs.chromium.org/p/skia/issues/detail?id=13783&q=GrDrawingManager%3A%3AreorderTasks&can=2 Soon after starting the slideshow, Skia calls get bogged down in a loop within GrDrawingManager::reorderTasks. This loop can take up to 20 seconds to complete with Skia/Metal enabled but, in most cases, the Skia watchdog thread will sense that the main thread is hung and will abort().
Created attachment 188268 [details] Sample file with transparent gradient over text
Created attachment 188395 [details] Sample file with transparent 3D shape
Created attachment 188419 [details] Crash log when opening attachement #188395 with --enable-dbgutil and Skia/Raster on macOS
Marking as resolved as all known issues on macOS have been fixed as of patch set 118 in the following Gerrit change: https://gerrit.libreoffice.org/c/core/+/114168
Created attachment 188515 [details] Screenshot of toolbar buttons with white background on Linux (gtk3) On Linux (with all of gtk3, kf5, gen), some toolbar buttons(like font background color) have white background in my test with PS 119 on top of master as of bcd3ae98a1292a02b8a2c56e114c6016a9a7df51, s. attachment.
Reopening. I'll check macOS tomorrow.
(In reply to Michael Weghorn from comment #28) > On Linux (with all of gtk3, kf5, gen), some toolbar buttons(like font > background color) have white background in my test with PS 119 on top of > master as of bcd3ae98a1292a02b8a2c56e114c6016a9a7df51, s. attachment. Rebuild was faster than expected. I also see this on macOS. I tested with both the Breeze and the Breeze (SVG) icons with Skia/Metal, Skia/Raster, and Skia disabled and the white background for those two background icons is white. It is subtle in light mode, but it is very, very obvious in dark mode.
The fix for the white background in the font color and font background color toolbar icons is in patch set 120 so marking as "resolved" again. Feel free to reopen if anyone finds any bugs with patch set 120.
Created attachment 188536 [details] Screenshot infobar with PS 120
(In reply to Patrick Luby from comment #31) > The fix for the white background in the font color and font background color > toolbar icons is in patch set 120 so marking as "resolved" again. I can confirm that fix on Linux. > Feel free to reopen if anyone finds any bugs with patch set 120. What I see with PS 120 is some small white rendering artifact in the infobar, just behind/next to the "x" button to close this, s. attachment 188536 [details]. Infobar can e.g. be triggered by removing the LO profile and starting LO.
(In reply to Michael Weghorn from comment #33) > What I see with PS 120 is some small white rendering artifact in the > infobar, just behind/next to the "x" button to close this, s. attachment > 188536 [details]. > > Infobar can e.g. be triggered by removing the LO profile and starting LO. I also see this on macOS with Skia enabled or disabled. Also, I see this with the current LibreOffice 7.6 Beta release but only when Skia is enabled.
(In reply to Patrick Luby from comment #34) > I also see this on macOS with Skia enabled or disabled. Also, I see this > with the current LibreOffice 7.6 Beta release but only when Skia is enabled. Patch set 122 fixes this on macOS.
Created attachment 188541 [details] Font background color in Breeze toolbar icon with gray horizontal line
(In reply to Patrick Luby from comment #36) > Created attachment 188541 [details] > Font background color in Breeze toolbar icon with gray horizontal line So I found one more case of an unexpected edge line in the font background color toolbar icon when the Breeze icons are used: https://bugs.documentfoundation.org/attachment.cgi?id=188541 It occurs with Skia/Metal, Skia/Raster, and Skia disabled with patch set 122. However, it also occurs in master and libreoffice-7-6 but only with Skia/Metal.
(In reply to Patrick Luby from comment #35) > Patch set 122 fixes this on macOS. I confirm that this fixes it for Linux as well, can't reproduce with git master as of 81994cb2b8b32453a92bcb011830fcb884f22ff3 (i.e. with the change being merged already).
(In reply to Patrick Luby from comment #37) > So I found one more case of an unexpected edge line in the font background > color toolbar icon when the Breeze icons are used: > > https://bugs.documentfoundation.org/attachment.cgi?id=188541 Marking as resolved/fixed. I found that the above bug only occurs with Skia/Metal enabled just like in the libreoffice-7-6 and master branches so it is not caused by this Gerrit change and it is, instead, a regression caused by the fix for https://bugs.documentfoundation.org/show_bug.cgi?id=156361.
(In reply to Michael Weghorn from comment #28) > Created attachment 188515 [details] > Screenshot of toolbar buttons with white background on Linux (gtk3) > > On Linux (with all of gtk3, kf5, gen), some toolbar buttons(like font > background color) have white background in my test with PS 119 on top of > master as of bcd3ae98a1292a02b8a2c56e114c6016a9a7df51, s. attachment. Not sure if I should report this here or in a separate report, but I'm seeing the same type of issue as in the screenshot in the properties deck of the sidebar (with Colibre icons) in Writer/Calc/Draw. Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e26aeb882dd236adf19679d5df9b7ba5da1ed226 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded
(In reply to Telesto from comment #40) > Not sure if I should report this here or in a separate report, but I'm > seeing the same type of issue as in the screenshot in the properties deck of > the sidebar (with Colibre icons) in Writer/Calc/Draw. Now that the change has been merged, I think it makes sense to open separate bugs for things that show up. For this one, I've opened tdf#156629.
(In reply to Michael Weghorn from comment #41) > Now that the change has been merged, I think it makes sense to open separate > bugs for things that show up. For this one, I've opened tdf#156629. Sounds good to me.