Description: macOS: Writer freezes when opening Writer document with large page filling shapes with Skia/Metal Steps to Reproduce: 1. Open attachment 200936 [details] (bug 166709) with Skia/Metal on Actual Results: Freezes Expected Results: Opening the file, like Skia/Raster Reproducible: Always User Profile Reset: No Additional Info: Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: c854f5aaae575a0570f79a225b80b53ed420578c CPU threads: 8; OS: macOS 14.7.4; UI render: Skia/Metal; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Patrick: thought you might be interested in this one since it concerns macOS.
I really don't have any spare time right now so can someone attach an Activity Monitor log? That will at least tell us where in the code the hang is occurring. Also, since this only occurs with Skia/Metal, it's probably something about drawing directly to the GPU instead of CPU so does it occur with Skia/Vulkan on Windows or Linux?
@Stuart Would you mind to check if you can open the file (quickly) on Windows with Skia/Vulkan enabled. The file doesn't open for me with Skia/Metal (or it takes way to long)
Created attachment 200957 [details] Screenshot Instruments
Also with Version: 25.2.0.3 (X86_64) / LibreOffice Community Build ID: e1cf4a87eb02d755bce1a01209907ea5ddc8f069 CPU threads: 8; OS: macOS 14.7.4; UI render: Skia/Metal; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded Fine with Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b38974391e8d4bf0d450abfaa86bbccbe1022995 CPU threads: 8; OS: macOS 14.7.4; UI render: Skia/Metal; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
The commit identified at bug 166709 might be related
(In reply to Telesto from comment #4) > Created attachment 200957 [details] > Screenshot Instruments From my quick look at your snapshot, it looks like LibreOffice is copying SkiaSalGraphicsImpl::copyBits() (i.e. in the middle of the selected calls) is the topmost call into Skia/Metal so I added a debug statement in the debug patch below to see how frequently that is being called. With the following debug patch in my local master build and running in a Terminal with the document in comment #0, I see thousands of calls per minute to SkiaSalGraphicsImpl::copyBits() copying 13 x 13 pixels at a time. I don't know much about all the "drawinglayer" code that generates these calls, but AFAIK the rule of thumb for GPU drawing is that drawing to a GPU can be much faster than drawing to CPU memory but extracting pixels from the GPU can be much much slower than doing so from CPU memory. I may be wrong, but I don't think this will be fixable down in LibreOffice Skia code and a different approach for copying tens of thousands of 13 x 13 pixels from one GPU surface to another: diff --git a/vcl/source/outdev/outdev.cxx b/vcl/source/outdev/outdev.cxx index 43b6650ce4e8..752e1f2c0a64 100644 --- a/vcl/source/outdev/outdev.cxx +++ b/vcl/source/outdev/outdev.cxx @@ -638,6 +638,7 @@ void OutputDevice::DrawOutDevDirectProcess(const OutputDevice& rSrcDev, SalTwoRe mpGraphics->CopyBits( aPosAry2, *pSrcGraphics, *this, rSrcDev ); return; } +fprintf(stderr, "Here: %p %li %li %li %li\n", pSrcGraphics, rPosAry.mnSrcWidth, rPosAry.mnSrcHeight, rPosAry.mnDestWidth, rPosAry.mnDestHeight); if (pSrcGraphics) mpGraphics->CopyBits( rPosAry, *pSrcGraphics, *this, rSrcDev ); else
(In reply to Patrick (volunteer) from comment #7) > I may be wrong, but I don't think this will be fixable down in LibreOffice > Skia code and a different approach for copying tens of thousands of 13 x 13 > pixels from one GPU surface to another: Forgot to add that I cannot reproduce this in 24.8.6.2 (i.e. the current Mac App Store version) but I can reproduce this in 25.2.3.2 so a bibisect might be the fastest way to find out where this loop of copying pixels was added in Impress or drawinglayer code. I tried reverting Armin's commit https://git.libreoffice.org/core/+/462d85709ead9c7cec33ce58fc608997263cb6aa%5E%21/ but it wouldn't apply to master so I cannot confirm that that is the commit that is causing this bug.
Created attachment 200958 [details] WinDbg stack trace of attachment opening in Win11 w/Vulkan LO 25.2.3.2 (In reply to Telesto from comment #3) > @Stuart > Would you mind to check if you can open the file (quickly) on Windows with > Skia/Vulkan enabled. The file doesn't open for me with Skia/Metal (or it > takes way to long) Stalls also on Windows builds. Version: 25.2.3.2 (X86_64) / LibreOffice Community Build ID: bbb074479178df812d175f709636b368952c2ce3 CPU threads: 8; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded Attached to WinDbg produces attached stack
(In reply to V Stuart Foote from comment #9) > Created attachment 200958 [details] > WinDbg stack trace of attachment opening in Win11 w/Vulkan LO 25.2.3.2 > > (In reply to Telesto from comment #3) > > @Stuart > > Would you mind to check if you can open the file (quickly) on Windows with > > Skia/Vulkan enabled. The file doesn't open for me with Skia/Metal (or it > > takes way to long) > > Stalls also on Windows builds. > > Version: 25.2.3.2 (X86_64) / LibreOffice Community > Build ID: bbb074479178df812d175f709636b368952c2ce3 > CPU threads: 8; OS: Windows 11 X86_64 (10.0 build 22631); UI render: > Skia/Vulkan; VCL: win > Locale: en-US (en_US); UI: en-US > Calc: threaded > > Attached to WinDbg produces attached stack No issues opening in Skia non-Vulkan software raster rendering, Vulkan only.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1f61a2ec4e252d2eeccabd65a10650c8ee231a1b tdf#166715 speed up transparent fill operation It will be available in 25.8.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.
Tested the fix in my local master build and the file in comment #0 now opens instantaneously: Version: 25.8.0.0.alpha1+ (AARCH64) / LibreOffice Community Build ID: b4460d983401e0b5962f71159016209e2d74d095 CPU threads: 8; OS: macOS 15.5; UI render: Skia/Metal; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/f6f5a4df5ecfc4505a3fa6bb0b4b027ac9571fb5 tdf#166715 speed up transparent fill operation It will be available in 25.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.
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-25-2-4": https://git.libreoffice.org/core/commit/df21ef06fbbc2495f652a7cbd14b5089dfe691f8 tdf#166715 speed up transparent fill operation It will be available in 25.2.4. 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.
simplify targets.