Description: 1) Start LibreOffice 2) The default Skia options are now all activated (Use Skia for all rendering and Skia software raster 3) The StartCenter window is displayed. 4) With the mouse, resize the window (larger or smaller than initial size) 5) Black areas of the window are displayed unfilled, until the mouse is released. 6) If software Skia rendering is then deactivated, the StartCenter window is resized but parts of the UI only redrawn when the mouse moves over the UI element, otherwise a black space remains on the canvas. Steps to Reproduce: See above. Actual Results: StartCenter window not redrawn correctly on window resize Expected Results: StartCenter window should be redrawn correctly, as the window is being resized. Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.5.0.1 (AARCH64) / LibreOffice Community Build ID: 77cd3d7ad4445740a0c6cf977992dafd8ebad8df CPU threads: 8; OS: Mac OS X 13.0.1; UI render: Skia/Metal; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded
Confirm Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8635c9aa8c6f1078a9e220076d5a08daf30077e8 CPU threads: 8; OS: Mac OS X 12.3.1; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded I noticed the same on Windows in the past, unsure if it's still the case..
(In reply to Telesto from comment #1) > I noticed the same on Windows in the past, unsure if it's still the case.. Bug 136241 seems a good candidate
(In reply to Telesto from comment #2) > (In reply to Telesto from comment #1) > > I noticed the same on Windows in the past, unsure if it's still the case.. > > Bug 136241 seems a good candidate It does indeed. I wonder if the recent fixes to VCL scheduling to prevent crashing on macOS (e.g. bug 148435) have had an unintended consequence and caused this bug to come back ? @Lubos : any ideas ?
Let's have a guess at commit 8b442d7fae17660b3665da2c1f7a084341987693 overriding Luboš' commit from bug 136241
@Noel, Michael : thoughts ?
(In reply to Alex Thurgood from comment #3) > I wonder if the recent fixes to VCL scheduling to prevent crashing on macOS > (e.g. bug 148435) have had an unintended consequence and caused this bug to > come back ? > > @Lubos : any ideas ? Unrelated, same issue with 7.4.3
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d118be7ed4dd6596a8b4d766e8507b6dcaf2b7f7 Related: tdf#152703 Eliminate empty window with Skia/Metal while resizing It will be available in 7.6.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.
(In reply to Commit Notification from comment #7) > Related: tdf#152703 Eliminate empty window with Skia/Metal while resizing > > It will be available in 7.6.0. Note: this patch does *not* fix this bug. Instead, it fixes a related bug that causes the entire window to be empty during resizing when Skia/Metal is enabled. With my fix, resizing with Skia/Metal enabled will behave the same as either Skia/Raster or Skia disabled.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/f889570b3a70f5e03d8ae7ff7102f3225b512b66 Related: tdf#152703 Eliminate empty window with Skia/Metal while resizing It will be available in 7.5.0.2. 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 "master": https://git.libreoffice.org/core/commit/3f7406bc4df3c7d6cc618312607bff1ec36a12f7 tdf#152703 Force relayout during live resizing of window It will be available in 7.6.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 posted the following patch that I think fixes all of the various macOS "live resizing" issues mentioned in this bug: https://gerrit.libreoffice.org/c/core/+/145053 The patch still needs to be reviewed and tested before it appears in a nightly build, but it should fix the following: 1. During live resizing, the window contents should resize and redraw as the window changes size. Note: there can be a little bit of a lag as I assume that the application code (Writer, Calc, etc.) appear to coalesce resize events by periodically redrawing in a timer. 2. When live resizing ends by releasing the mouse button or trackpad, one last resize and redraw should now occur. 3. Live resizing while using Skia/Metal should no longer flicker.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2d1a0d86d2d0c00fcfee61c39f2221e786e4245b Related: tdf#152703 Prevent possible hang when live resizing a window It will be available in 7.6.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.
This is improved in Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5a1ddc1a92a7883597ab7d825408a1f0adc2ec6e CPU threads: 8; OS: Mac OS X 13.1; UI render: Skia/Raster; VCL: osx Locale: de-DE (en_DE.UTF-8); UI: en-US Calc: threaded When changing window size of start center still seeing artefacts and the window being redrawn, but it is much quicker now. Guess it is fair to call this fixed nonetheless.
(In reply to steve from comment #13) > When changing window size of start center still seeing artefacts and the > window being redrawn, but it is much quicker now. Guess it is fair to call > this fixed nonetheless. I did some testing with a 100+ page Writer document. I rapidly resized the width of the document and the redrawing lag was usually no more than less than a second. However, after about 15 or 20 seconds of continuous rapid resizing, the redraw lag would sometimes jump to several seconds or more and, occasionally, stop redrawing completely until I moved my mouse. I have posted the following new patch that hopefully fixes the blocked redraws that I saw: https://gerrit.libreoffice.org/c/core/+/145211 The patch still needs to be reviewed and tested before it appears in a nightly build, but below is an explanation of what I changed. In LibreOffice, a resize event doesn't immediately relayout and redraw the window's contents. Instead, a resize event appears to queue a background tasks to do the relayout and redraw. Hence the slight redraw lag when in live resizing. So my previous patch would stop native event dispatching (macOS floods LibreOffice with windowDidResize: events during live resizing) and let any queued background tasks run. With my previous patch, queued background tasks were running, but the problem was some long-running, low priority background tasks, such as spellcheck and Writer pagination, were also firing and those background tasks would block any screen updates until they finished. In my new patch, low priority queued background tasks are skipped when live resizing a window. The redraw lag will still be there, but the lag time should hopefully now be consistently short.
@Patrick, Your fixes do seem to have resolved the redraw lag with the StartCenter. However, I get a repeatable SIGSEGV when resizing the StartCenter window now. 1) Start LibreOffice 2) Use the mouse to select the bottom right hand corner of the StartCenter window. 3) Resize the window continuously, moving the mouse up and down, and left to right, and then with the mouse button still pressed down, try reducing the window size moving right to left to the point where the document preview window disappears and only the left edge (with action buttons) remains displayed. Further movement of the mouse cursor to the left cause the whole of the main LO window to disappear and the Apple trace dialog is displayed. Attaching Apple trace details here. The question is whether this is something related to your patches, or whether it is yet another Skia bug.
Created attachment 184618 [details] Sigsegv crash trace
(In reply to Alex Thurgood from comment #16) > Created attachment 184618 [details] > Sigsegv crash trace Tested with Version: 7.6.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: d2a27ceece84998c686477ffd2073f3516b568a7 CPU threads: 8; OS: Mac OS X 13.0.1; UI render: Skia/Metal; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded daily build from master (MacOSX-aarch64@tb92-TDF) 2023-Jan-11 06:25
I can reproduce the crash. Your stack trace indicates that my patches that are in the nightly build are causing an infinite recursion of AquaSalInstance::DoYield() calls (you can see that the same few functions repeat in the Thread 0 stack trace). Fortunately, my latest patch fixes this infinite recursion: https://gerrit.libreoffice.org/c/core/+/145211 With the above patch, I don't get a crash. Unfortunately, that patch has not been committed yet and is still waiting for review. Can you retry when the above patch gets committed and included in the night build?
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/fed429e4f6f437997aa6a88e2d071f58aa00ee34 Related: tdf#152703 Eliminate potential blocking during live resize It will be available in 7.6.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.
My latest patch is now in the nightly build so marking resolved/fixed. If you see any new crashes, feel free to reopen.
Verified with Version: 7.6.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: d50eca2a30bdabdc1735c590d6ec1913c6dd22fd CPU threads: 8; OS: Mac OS X 13.0.1; UI render: Skia/Metal; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded Thanks Patrick !
I just wanted to summarized which patches will appear in which version of LibreOffice. The latest patches will be in LibreOffice 7.6. But the last few patches made some significant changes to the code (i.e. they are riskier changes) so LibreOffice 7.5 will only have the "eliminate empty window with Skia/Metal while resizing" patch: https://git.libreoffice.org/core/commit/f889570b3a70f5e03d8ae7ff7102f3225b512b66 Hopefully after a few weeks of use we can consider the latest patches as reasonably tested and, if no more problems (crashing or otherwise) are reported, I will add the latest patches for inclusion in LibreOffice 7.5.1.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/0a6e128ef6c5f3951873e28931f331591759ae5f tdf#152703 Force relayout during live resizing of window It will be available in 7.5.1. 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.