Description: Upgraded and now scrolling in multi-page Writer documents is laggy, i.e. the visualization is jerky/not smooth. Same result in dark and light mode. This behavior is more pronounced with more text and with track changes enabled and with comments. Build: 9f56dff12ba03b9acd7730a5a481eea045e468f3 Steps to Reproduce: 1. Enter text 2. Scroll up and down Actual Results: Laggy scrolling Expected Results: Smooth scrolling behavior Reproducible: Always User Profile Reset: Yes Additional Info: In safe mode the problem was less severe but still laggy. Maybe this is as good as it gets.
Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b40e469887d973e1eea242749a90c3c2370da3a5 CPU threads: 8; OS: macOS 13.6.1; UI render: Skia/Raster; VCL: osx Locale: en-US (en_DE.UTF-8); UI: en-US Calc: threaded Scrolling is indeed very laggy and not smooth at all. Scrolling attached sample writer document e.g. jumps form page 6 to page 1. This is two finger scrolling using internal and external touchpad. Grabbing the scrollbar handle also does not allow smooth scrolling. It similarly jumps around the document when being dragged up or down. new, hardware all since I reproduced on intel mac (op report was for arm). Adjusted title, reported on macOS 12, persisting with macOS 13.
Created attachment 190513 [details] testfile.odt
I just opened the testfile and can partially confirm this bug on the latest release (7.6.2.1). The only thing that is weird in my case, is that after initial jerky scrolling on the test document in the first pages, suddenly scrolling becomes very smooth, both up and down and across all pages. The jerky/laggy scrolling therefore only appears in the beginning. This is on a 14 inch M2 Macbook Pro. I will see what happens when I open the test document on my other Macs and report back. Version: 7.6.2.1 (AARCH64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 10; OS: Mac OS X 13.6.1; UI render: Skia/Metal; VCL: osx Locale: en-GB (en_GB.UTF-8); UI: en-GB Calc: threaded
Not reproducible in Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9704f61982360ce35983a61cca3fd00bbdf51ab6 CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: x11 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded
(In reply to Xisco Faulí from comment #4) > Not reproducible in > > Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: 9704f61982360ce35983a61cca3fd00bbdf51ab6 > CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: x11 > Locale: es-ES (es_ES.UTF-8); UI: en-US > Calc: threaded I cannot reproduce the bug either when Skia is disabled. But, with Skia/Metal or Skia/Raster I see the bug. So, my first guess is that we need to add more "flush to screen" calls somewhere in the Skia code.
I have a fix in the following patch: https://gerrit.libreoffice.org/c/core/+/158853
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9c0803edd1f42b2d29115674795c7c674fea1a35 tdf#155266 flush when scrolling or dragging It will be available in 24.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 my fix for this bug and it will be included in tomorrow's (04 November 2023) nightly master build. Once someone is able to confirm that the bug is fixed, I will backport the fix back to LibreOffice 7.6 and 7.5.
@Patrick, wouldn't some similar additional flush events during mouse wheel scroll or drag also be of value for UNX and Win? Luboš had set up Skia's initial output device flushing with [1]. =-ref-= [1] https://gerrit.libreoffice.org/c/core/+/103675
(In reply to V Stuart Foote from comment #9) > @Patrick, wouldn't some similar additional flush events during mouse wheel > scroll or drag also be of value for UNX and Win? Luboš had set up Skia's > initial output device flushing with [1]. Maybe. Maybe not. This bug occurs on macOS because, in the macOS native event handling code, AquaSalFrame::Flush() calls were ignored when dispatching a native event. That is, at least on macOS, flushes weren't happening unless AquaSalFrame::Flush() was called during "idle time". I am not very familiar with the Windows or Linux native event dispatching code, nor do I have access to any non-macOS machines, so I can't determine if those platforms have the same problem or not.
Created attachment 190649 [details] Screen Recording 2023-11-04
Patrick, thanks so much for picking up this issue and submitting your patch. I tested todays main build: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e963da8716a9e418ff220f0c0b5299dcaa82f53a CPU threads: 8; OS: macOS 13.6.1; UI render: Skia/Raster; VCL: osx Locale: en-US (en_DE.UTF-8); UI: en-US Calc: threaded and there are a few remaining issues in regards to scrolling a writer document. - the "Pages n of n" information gets butchered while scrolling is in progress. There are artifacts and text is partly missing when the scroll process is going on - the document goes "out of sync" as in: there is a part on the right side that is not scrolled to the same location as the rest of the UI on the left side - scrolling is still very slow, you can see this in the end of the screencast where I drag the scrollbar instead of using two finger trackpad scroll, which I use in the beginning of the screencast Hope this is somewhat useful feedback. Do you want this in a separate new issue or should we re-open this one here?
Or maybe that build didn't yet have your patch?
I downloaded the 04 November 2023 nightly master build this morning from the following link: The build ID in my build points to a commit on 04 November 2023 but your build ID points to a commit on 03 November 2023 so maybe the Intel builds don't have my commit yet?: 24.2.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: d7a5e7643f3540b1490c1e2f1a91ff86c721d7b6 CPU threads: 8; OS: macOS 14.0; UI render: Skia/Metal; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded For me, dragging the mouse thumb is very smooth. There still is some jumps when scrollwheeling over several pages. Scrollwheeling continuously within a page renders the scroll thumb pretty smooth.
(In reply to Patrick Luby from comment #14) > I downloaded the 04 November 2023 nightly master build this morning from the > following link: Forgot the link: https://dev-builds.libreoffice.org/daily/master/current.html
(In reply to Patrick Luby from comment #14) > The build ID in my build points to a commit on 04 November 2023 but your > build ID points to a commit on 03 November 2023 so maybe the Intel builds > don't have my commit yet?: Bad news: my commit 9c0803edd1f42b2d29115674795c7c674fea1a35 was earlier than the build ID in your LibreOffice > About dialog so my code is in the build that you downloaded. Maybe my fix only makes a difference on Silicon Macs? Or only on macOS Sonoma?
(In reply to Patrick Luby from comment #16) > Maybe my fix only makes a difference on Silicon Macs? Or only on macOS > Sonoma? @steve I rewatched your screen recording and noticed that spellchecking had added wavy lines in the first pages of your document, but not in later pages. This makes me think that Writer is spending a lot of time in spellchecking. What happens if you uncheck the Tools > Automatic Spell Checking menu item and reload your document? For me, Writer is a bit slow to respond to scrollwheel and drag events for the first few seconds while it finishes laying out all of the pages, but after that updating of the scrollbar is responsive.
Nice spotting. However also with Automatic spell checking disabled scroll behavior does not improve on this old intel MacBookPro from 2017. All behaviors mentioned earlier remain the same. If looking at this problem on this very mac would be of any help, don't hesitate to let me know and we can schedule something.
(In reply to steve from comment #18) > Nice spotting. However also with Automatic spell checking disabled scroll > behavior does not improve on this old intel MacBookPro from 2017. OK. So here's what I am thinking: I can easily see the bug in my local Mac Silicon build without my patch. Local builds run slower so the bug is really obvious but not so much in LibreOffice 7.6 download. Anyway, my patch fixes the bug on Mac Silicon so I think it is a good bet that the bug is caused by failure to flush to the screen. So, my current theory is that Intel Macs aren't getting to my fix any faster than before. Could be that Intel Macs take a lot more time to grind through the native pending events queue and flush is only called when there are no more native pending events.
(In reply to Patrick Luby from comment #19) > So, my current theory is that Intel Macs aren't getting to my fix any faster > than before. Could be that Intel Macs take a lot more time to grind through > the native pending events queue and flush is only called when there are no > more native pending events. I have uploaded the following patch that implements this approach. The macOS build server seems to be very backed up so we'll see if I can commit it before tomorrow's (07 November 2023) nightly master build: https://gerrit.libreoffice.org/c/core/+/159003
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/55a0fba06086436260aca1f7367da376683afdaa tdf#155266 revert commit 9c0803edd1f42b2d29115674795c7c674fea1a35 It will be available in 24.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.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0c54c09aeb7e170512195c8f619ab2ded98c1ec5 tdf#155266 force flush after scrolling It will be available in 24.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.
(In reply to Patrick Luby from comment #20) > I have uploaded the following patch that implements this approach. The macOS > build server seems to be very backed up so we'll see if I can commit it > before tomorrow's (07 November 2023) nightly master build: > > https://gerrit.libreoffice.org/c/core/+/159003 The backlog cleared and I was able to commit my latest patch. It should be in tomorrow's (07 November 2023) nightly master build. I will be interested to see if there is any improvement on Intel Macs with this patch.
mac build infra is in limbo atm. Waiting for that to recover.
(In reply to steve from comment #24) > mac build infra is in limbo atm. Waiting for that to recover. All links in the following site stop downloading after a second or two for me as well: https://dev-builds.libreoffice.org/daily/master/current.html
Created attachment 190706 [details] Screen Recording 2023-11-07 Main builds can be downloading again, although still somewhat slow. Tested on two macs and interestingly they behave differently. 2012 iMac, macOS 13.6.1 via OpenCoreLegacyPatcher: - no scroll issues: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 0bf60e32c0ac2bf79fad6c29c39c6f6a3f9ce8e8 CPU threads: 4; OS: macOS 13.6.1; UI render: Skia/Metal; VCL: osx Locale: en-US (en_DE.UTF-8); UI: en-US Calc: threaded 2017 MacBook Pro, macOS 13.6.1 however does have trouble: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 0bf60e32c0ac2bf79fad6c29c39c6f6a3f9ce8e8 CPU threads: 8; OS: macOS 13.6.1; UI render: Skia/Raster; VCL: osx Locale: en-US (en_DE.UTF-8); UI: en-US Calc: threaded Processor Name: Quad-Core Intel Core i7 Chipset Model: Intel HD Graphics 630 Type: GPU Really unsure if scrolling is less laggy but it still isn't great on that mac. To get an idea of the current state attaching another screencast.
(In reply to steve from comment #26) > Really unsure if scrolling is less laggy but it still isn't great on that > mac. To get an idea of the current state attaching another screencast. Your latest screencast looks like what I see in my local master build without any of my fixes. With automatic spellchecking unchecked, I see the same "stickiness" when swiping on the trackpad with two fingers and the lagging when dragging the scrollbar downward. It is very good news that the fix works on one of your Intel Macs so I wonder what could be different when using your 2017 MacBook Pro. Do you see the same buggy behavior if you disable Skia (both Skia settings unchecked)? I could never reproduce this bug with Skia disabled.
2017 mac has a dedicated GPU which is one difference. I noticed 2017 mac uses Skia/Raster and 2012 mac uses Skia/Metal. Switching 2017 mac to skial/metal results in smooth and perfect scrolling. Back to skia/raster -> back to laggy scrolling. Switch 2012 mac to skia/raster -> laggy scrolling on 2012 mac. So not at all mac dependent but skia/raster being a problem. Sidenote: the inconsistency of the skia naming is confusing. About and Settings should use the same terminology. This is confusing already, why make it harder?
(In reply to steve from comment #28) > So not at all mac dependent but skia/raster being a problem. Hmmm. I cannot reproduce the bug with Skia/Raster on my Mac Silicon MacBook Pro. So I am guessing that there is some Intel-specific performance bug in Skia's raster code: Version: 24.2.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 0bf60e32c0ac2bf79fad6c29c39c6f6a3f9ce8e8 CPU threads: 8; OS: macOS 14.0; UI render: Skia/Raster; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/b8910f2a00119e2de136b00567d5f9704f84ac25 tdf#155266 force flush after scrolling It will be available in 7.5.9. 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-7-6": https://git.libreoffice.org/core/commit/8e8fc0b62965596c3c1ec37a4062ebb6a3d154fd tdf#155266 force flush after scrolling It will be available in 7.6.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.
*** Bug 158538 has been marked as a duplicate of this bug. ***
(In reply to steve from comment #28) > Switching 2017 mac to skial/metal results in smooth and perfect scrolling. > Back to skia/raster -> back to laggy scrolling. Same here Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 1a74a87b442857567d20da5dc97bbbc278745afd CPU threads: 8; OS: macOS 13.4.1; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded Also in Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5682e1d4145c26fc8021879df0543d5aeacf9c83 (19 november) CPU threads: 8; OS: macOS 13.4.1; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded Still OK with build from 11 september Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: cea165a3ebdb5f2a2b172004ff1b3848f303d78a CPU threads: 8; OS: Mac OS X 13.4.1; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded -- It's not Skia Raster specific. It's also slow with Skia disabled
Created attachment 191263 [details] Partial Xcode Instruments trace without Skia enabled
(In reply to Telesto from comment #34) > Created attachment 191263 [details] > Partial Xcode Instruments trace without Skia enabled I don't have an Intel development machine anymore. I only have a Silicon Mac. But what I see in your Instruments trace is that most of the time is being spent copying LibreOffice's offscreen drawing surface to the native window. In other words, LibreOffice is flushing more frequently than the slower Intel machines can handle whereas Silicon machines can easily keep up with the load. So, the question for Intel testers is should I just limit my fix to Silicon Macs? I have uploaded the following patch which cuts down on the number of times the that LibreOffice copies its drawing surface to the native window while scrolling rapidly. But it only cuts the number of copies by about 25%. Not sure that will be enough for Intel users though so maybe rolling back my fixes for Intel only might be the better option?: https://gerrit.libreoffice.org/c/core/+/160399
(In reply to Patrick Luby from comment #35) > So, the question for Intel testers is should I just limit my fix to Silicon > Macs? I have tendency to say no. If it's some kind of hardcoded approach (except for allow/deny). In general it makes code complicate and bug discovery hard if there are all sorts of special cases. Especially if you say it's caused by overwhelmed system by calls. Which suggests that it's not really efficient on CPU cycles. My impression: it's more like band aid/quick fix. Hitting the CPU hard should be battery drain on ARM too, I guess. > I have uploaded the following patch which cuts down on the number of > times the that LibreOffice copies its drawing surface to the native window > while scrolling rapidly. But it only cuts the number of copies by about 25%. > Not sure that will be enough for Intel users though so maybe rolling back my > fixes for Intel only might be the better option?: > > https://gerrit.libreoffice.org/c/core/+/160399 I should have mentioned this: the Instruments code is done not by scrolling but simply selecting a paragraph of text (highlighting took 3 seconds to appear) --- My personal take. * Split comment 1 into a new bug. Comment 0 is talking about Track Changes enabled and Comments balloons. Comments are notoriously known to render slowly (cross platform issue, see bug 61558). Probably the same for track changes stuff etc. The problem is not Mac specific * Comment 1: needs a new fix, IMHO. If the bug still present at revert. The scope of the current fix appears to be off. It affects all modules Writer/Calc/Impress/Draw and more backends (Skia/Raster and OSX). The bug needs be constrained preferably to the area of the problem: multi-page view to limit fall-out. The Multi-page view can be jerky in Windows too, except surely not as bad as shown in screencast for plain text.
(In reply to Telesto from comment #36) > I should have mentioned this: the Instruments code is done not by scrolling > but simply selecting a paragraph of text (highlighting took 3 seconds to > appear) What does this have to do with my fix? My fix only flushes when you are scrolling. I'm not doing something so stupid as to just continually flush. > * Comment 1: needs a new fix, IMHO. If the bug still present at revert. The > scope of the current fix appears to be off. It affects all modules > Writer/Calc/Impress/Draw and more backends (Skia/Raster and OSX). The bug > needs be constrained preferably to the area of the problem: multi-page view > to limit fall-out. The Multi-page view can be jerky in Windows too, except > surely not as bad as shown in screencast for plain text. And rapid scrolling doesn't use battery? Seriously, scrolling causes nearly the entire window content to be redrawn because everything in the document has moved. Yet, my fix's extra flush that only occurs while scrolling (i.e. after you have forced the window's content to change many times rapidly) is a battery drain? I am just a volunteer working on LibreOffice in my spare time as a hobby. I have tried to fix it. My fix seems to work on Silicon Macs but not on most Intel Macs. That's good enough for me but I'll revert all of the changes if my fix has made Intel Mac worse. But I don't have another fix "waiting in the wings" so the Intel Mac testers need to decide what you want as a group: revert or keep my fix. Note that "keep my fix" is the default"
(In reply to Patrick Luby from comment #37) > (In reply to Telesto from comment #36) > > I should have mentioned this: the Instruments code is done not by scrolling > > but simply selecting a paragraph of text (highlighting took 3 seconds to > > appear) > > What does this have to do with my fix? My fix only flushes when you are > scrolling. I'm not doing something so stupid as to just continually flush. Only mentioning that the backtrace I took isn't done while scrolling. Not even in multipage view. The UI is laggy in a whole (and across components) See bug 158538 > > * Comment 1: needs a new fix, IMHO. If the bug still present at revert. The > > scope of the current fix appears to be off. It affects all modules > > Writer/Calc/Impress/Draw and more backends (Skia/Raster and OSX). The bug > > needs be constrained preferably to the area of the problem: multi-page view > > to limit fall-out. The Multi-page view can be jerky in Windows too, except > > surely not as bad as shown in screencast for plain text. > > And rapid scrolling doesn't use battery? Seriously, scrolling causes nearly > the entire window content to be redrawn because everything in the document > has moved. Yet, my fix's extra flush that only occurs while scrolling (i.e. > after you have forced the window's content to change many times rapidly) is > a battery drain? I'm not a developer. So if this proper course of action, it is. I surely noticed that scrolling being a battery drain the extend is depending on backend used. > I am just a volunteer working on LibreOffice in my spare time as a hobby. I > have tried to fix it. My fix seems to work on Silicon Macs but not on most > Intel Macs. Your work is surely appreciated. > That's good enough for me but I'll revert all of the changes if > my fix has made Intel Mac worse. OK > But I don't have another fix "waiting in the wings" Ah, OK. > so the Intel Mac testers need to decide what you want as a group: revert or keep my fix. The group of OSX testers is quite small. Most feedback is given after release as end-user bug reports. >Note that "keep my fix" is the default" Lets see if the situation improves with the fix you have in mind. I might do a bibisect for bug 158538 to be sure about the cause of the problem I'm noticing.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0ddd9f7e055a0c1ecb120de3e40c3fdb8373e9dc Related: tdf#155266 skip redisplay of the view when forcing flush It will be available in 24.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.
(In reply to Telesto from comment #38) > Lets see if the situation improves with the fix you have in mind. I might do > a bibisect for bug 158538 to be sure about the cause of the problem I'm > noticing. OK. My latest patch is now committed and should be in tomorrow's (07 December 2023) nightly master build. What I am most interested in is whether things are worse on Intel Macs. I think your September 2023 build should give a good comparison. If tomorrow's nightly master build ends up being worse than your September 2023, can you see if it is also worse when using Skia/Metal? My memory is fuzzy, but in I remember this bug (at least the portion that I fixed) only occurring with Skia/Metal or Skia/Raster. I know that Skia/Metal requires much more flushing than Skia/Raster so it will be interesting if things are different between the two Skia settings.
That's fine with me. Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 0ddd9f7e055a0c1ecb120de3e40c3fdb8373e9dc CPU threads: 4; OS: macOS 12.7.1; UI render: Skia/Raster; VCL: osx Locale: pt-PT (pt_PT.UTF-8); UI: en-US Calc: threaded
(In reply to Patrick Luby from comment #40) > (In reply to Telesto from comment #38) > > Lets see if the situation improves with the fix you have in mind. I might do > > a bibisect for bug 158538 to be sure about the cause of the problem I'm > > noticing. > My memory is fuzzy, but in I remember this bug (at least the portion that I > fixed) only occurring with Skia/Metal or Skia/Raster. I know that Skia/Metal > requires much more flushing than Skia/Raster so it will be interesting if > things are different between the two Skia settings. Basic testing shows the performance being back to the state of 11 september with (using the description of bug 158538) Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 0ddd9f7e055a0c1ecb120de3e40c3fdb8373e9dc CPU threads: 8; OS: macOS 13.4.1; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded FWIW: The issue described at comment 33 was limited to OSX rendering and Skia/Raster. Skia/Vulkan has been working smooth and snappy all the time. --- Related to comment 1, scrolling attachment 190513 [details] * Scrolling single page view with Skia/Raster is acceptable, but slowish compared to Skia/Vulkan. The biggest issue: you can clearly see the red underlining disappearing while scrolling (swiping) with Skia/Raster an re-appearing after stopping scrolling. It's impossible to find some spelling error by quickly scrolling the document. Not observed with Skia/Vulkan * Scrolling (swiping) in multi-page view (3 pages in a row) still slow with Skia/Raster. Workable, but slowish. Problem is worse, if spell checker being busy marking stuff as spelling mistake (copy the text and pasted it couple of times and did some scrolling). The red lining is visible (doesn't vanish) while scrolling. ---- Scrolling (swiping a spreadsheet in Calc is on par with 11 september with Skia/Raster but also slow compared to Skia/Vulkan. If you're used to Skia/Vulkan scrolling, you surely not want fallback to use Skia/Raster
(In reply to Telesto from comment #42) >The biggest issue: you can clearly see the red underlining disappearing while >scrolling (swiping) with Skia/Raster an re-appearing after stopping scrolling. >It's impossible to find some spelling error by quickly scrolling the document. >Not observed with Skia/Vulkan Correction, this isn't true. If spell-checker is still running in background and you keep swipping, the red-wave stuff appears to be paused. Or the spell checking is still running, but the red waves aren't painted. If you stop scrolling multiple paragraphs get a red wave at once. Spell checker is an idle process, so I guess it's paused. Side-note: It appears spell-checker red waves are added linear top to bottom. If you take a 800 page document, and go jump to page 700 quickly, you have to wait for red waves to appear. In other words: It doesn't prioritize the current view
Created attachment 191290 [details] Instruments backtrace swiping in multipage-view OSX rendering Instruments backtrace swiping in multipage-view OSX rendering Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 0ddd9f7e055a0c1ecb120de3e40c3fdb8373e9dc CPU threads: 8; OS: macOS 13.4.1; UI render: default; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded Unsure if we should move this to a new bug for sake for clarity
(In reply to Telesto from comment #43) > Correction, this isn't true. If spell-checker is still running in background > and you keep swipping, the red-wave stuff appears to be paused. Or the spell > checking is still running, but the red waves aren't painted. If you stop > scrolling multiple paragraphs get a red wave at once. Spell checker is an > idle process, so I guess it's paused. > > Side-note: It appears spell-checker red waves are added linear top to > bottom. If you take a 800 page document, and go jump to page 700 quickly, > you have to wait for red waves to appear. In other words: It doesn't > prioritize the current view My fix does not make any changes to Writer's document loading and layout code. I don't know anything about that code so my fix does not have any noticeable effect until *after* all document loading and layout is done. So, if you turn off automatic spellchecking as mentioned in comment 17, the bug that my patches fix is, when dragging the vertical scrollbar up and down rapidly, the "thumb" of the scrollbar would appear stuck in one position and would sometimes not reposition until you released the mouse or trackpad. You can see this behavior in the second half of the attached screen recording https://bugs.documentfoundation.org/attachment.cgi?id=190706. The vertical scrollbar is dragged up and down but the thumb doesn't move because the updated redrawing of the scrollbar has not been flushed to the screen. If my fix works, when dragging the vertical scrollbar up and down rapidly, the position of the "thumb" of the scrollbar should almost keep up with your dragging.
(In reply to Patrick Luby from comment #45) > My fix does not make any changes to Writer's document loading and layout > code. I don't know anything about that code so my fix does not have any > noticeable effect until *after* all document loading and layout is done. FWIW: I didn't intend to imply your patch being responsible for the issue as such. I'm more describing my observations > So, if you turn off automatic spellchecking as mentioned in comment 17, the > bug that my patches fix is, when dragging the vertical scrollbar up and down > rapidly, the "thumb" of the scrollbar would appear stuck in one position and > would sometimes not reposition until you released the mouse or trackpad. You > can see this behavior in the second half of the attached screen recording > https://bugs.documentfoundation.org/attachment.cgi?id=190706. The vertical > scrollbar is dragged up and down but the thumb doesn't move because the > updated redrawing of the scrollbar has not been flushed to the screen. > > If my fix works, when dragging the vertical scrollbar up and down rapidly, > the position of the "thumb" of the scrollbar should almost keep up with your > dragging. Multi-layered answer (multi-page view 3 pages in a row, in my case zoom-level 35%) * Skia/Vulkan With cea165a3ebdb5f2a2b172004ff1b3848f303d78a Press and hold the vertical scrollbar and moving up/down -> working nicely Scroll up/down by swiping -> scrollbar doesn't keep up With 0ddd9f7e055a0c1ecb120de3e40c3fdb8373e9dc Working superb. Everything fine * Skia/Raster. With da3dd48eaf9086f8ab28d6a6655f9a638e51433a Press and hold the vertical scrollbar and moving up/down -> working nicely Scroll up/down by swiping -> vertical scrollbar doesn't match position With cea165a3ebdb5f2a2b172004ff1b3848f303d78a Press and hold the horizontal scrollbar and moving up/down -> working nicely Scroll up/down by swiping -> vertical scrollbar doesn't match position With 0ddd9f7e055a0c1ecb120de3e40c3fdb8373e9dc Same as cea165a3ebdb5f2a2b172004ff1b3848f303d78a * OSX With da3dd48eaf9086f8ab28d6a6655f9a638e51433a Press and hold the vertical scrollbar and moving up/down -> You have to wait for a scroll. Scroll up/down by swiping -> page scroll choppy and scrollbar has a lag With cea165a3ebdb5f2a2b172004ff1b3848f303d78a Same as da3dd48eaf9086f8ab28d6a6655f9a638e51433a With 0ddd9f7e055a0c1ecb120de3e40c3fdb8373e9dc Scroll up/down by swiping -> page move faster (but choppy) compared to the vertical scrollbar --- Unsure what the future is for OSX rendering; I personally dislike a plethora of supported backends
(In reply to Telesto from comment #46) > * Skia/Raster. > > With da3dd48eaf9086f8ab28d6a6655f9a638e51433a > Press and hold the vertical scrollbar and moving up/down -> working nicely > Scroll up/down by swiping -> vertical scrollbar doesn't match position > > With cea165a3ebdb5f2a2b172004ff1b3848f303d78a > Press and hold the horizontal scrollbar and moving up/down -> working nicely > Scroll up/down by swiping -> vertical scrollbar doesn't match position > > With 0ddd9f7e055a0c1ecb120de3e40c3fdb8373e9dc > Same as cea165a3ebdb5f2a2b172004ff1b3848f303d78a I would expect Skia/Raster to be jumpy when swiping up and down like you see with Skia disabled. But it sounds like the scrollbar thumb is "stuck" and doesn't make the final jump. Is that correct? Or does the final jump occur but much slower than with Skia disabled?
Created attachment 191294 [details] Screencast
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/fe59e5ab1cb9c15a7ff8222319c5a8b7b8183243 Related: tdf#155266 skip redisplay of the view when forcing flush It will be available in 7.6.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.
(In reply to Telesto from comment #48) > Created attachment 191294 [details] > Screencast Thank you for the screencast. It appears to me that there is a missing "flush to screen" after the scrollbar is repainted. I did some debugging and one thing I noticed, at least in Writer, is that the scrollbars are not updated and repainted immediately. Instead, the update and repaint are done by a delayed timer. My current theory is that on slower machines, it takes longer to grind through the flood of swipe and/or scroll events and, by the time the scrollbar update and repaint timer finally gets a chance to fire, there are no pending flushes scheduled. So, I added another flush after drawing scrollbars in the following patch: https://gerrit.libreoffice.org/c/core/+/160440
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5ff701226b00963312cb2a78e77966d012b79c82 Related: tdf#155266 force flush after drawing native scrollbars It will be available in 24.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.
OK. So my latest "flush after drawing scrollbars" fix is now committed and it should be in tomorrow's (08 December 2023) nightly master build. Does anyone still see the "vertical scrollbar doesn't match position" when using Skia/Raster on your Intel Mac as described in comment 46 and shown in attachment https://bugs.documentfoundation.org/attachment.cgi?id=191294? I still expect the scrollbar to be "jumpy" when swiping up and down since Writer, when swiping up and down, seems to repaint the scrollbar only after a complete swipe has been handled.
Created attachment 191306 [details] Screencast I made quite a mistake yesterday, uploading the wrong screencast. That one was the same as posted before by steve Anyhow, I don't see a difference compared to yesterday, thumb scrolling was already quite OK. Scrollbar doesn't update while swipping, also with patch (as predicted) Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 5ff701226b00963312cb2a78e77966d012b79c82 CPU threads: 8; OS: macOS 13.4.1; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
(In reply to Telesto from comment #53) > Anyhow, I don't see a difference compared to yesterday, thumb scrolling was > already quite OK. Scrollbar doesn't update while swipping, also with patch > (as predicted) When I watch your screencast, I see how "sticky" and "jumpy" the scrollbar is when swiping up or down. But, what I do see is that eventually the scrollbar does catch up. So I did some debugging this morning and put a printf() statement in LibreOffice's -[SalFrameView scrollWheel:] where native scroll wheel and swipe events are handled. What surprised me is that after a do a swipe, even on a relative new Silicon MacBook Pro, it still took a little bit time (under a second but still a noticeable amount of time) for the last -[SalFrameView scrollWheel:] to be called. So, my new theory for swiping up and down on Mac Intel is that swiping overwhelms LibreOffice. One solution that I can try is to combine (coalesce) batches of scroll wheel and swipe events into a single event so that LibreOffice doesn't get bogged down repainting most of the window when there are several more events waiting to be dispatched. For example, if the native event queue has 10 swipe events in a row, instead of processing each event and repainting the window 10 times, we check if the next event is also the same type of event and, if yes, do nothing for the current event and add the current event's X and Y change to the next event. In this example, 10 events should only cause a single window repaint. In theory, that should make swiping in general more responsive.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/898d5d470e24a55556f2fb244fec24df33ba8855 Revert "Related: tdf#155266 force flush after drawing native scrollbars" It will be available in 24.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.
(In reply to Patrick Luby from comment #54) > So, my new theory for swiping up and down on Mac Intel is that swiping > overwhelms LibreOffice. One solution that I can try is to combine (coalesce) > batches of scroll wheel and swipe events into a single event so that > LibreOffice doesn't get bogged down repainting most of the window when there > are several more events waiting to be dispatched. Sorry to get everyone's hopes up but I have dad news: LibreOffice is already coalescing scroll wheel and swipe events. The problem is that macOS only adds a few events at a time to the native event queue so every time the code tries to coalesce all the swipe events in the queue, there are at most only 2 or 3 swipe events in the queue that can be coalesced. Clearly macOS really wants LibreOffice to repaint after every few swipe events. I even used a few hacky methods to briefly sleep to allow macOS to fill the queue with more swipe events but that made the scrollbar even more "sticky" and "jumpy". Unfortunately, I am all out of ideas at this point so I'll just leave this bug open in case I get any ideas in the future.
(In reply to Patrick Luby from comment #56) This bug should be marked fixed and being closed and a new clean bug for other/remaining issues
Setting status back to New and unassigning myself. While I fixed some Skia flushing issues, the majority of the comments in this bug are complaints about the slow performance and jumpy behavior of swiping in a document on Intel Macs so that is what this bug will remain so that the next developer won't have to redo all the troubleshooting that I have documented.
Libra office 7.5.9.2 was supposed to fix jerky scrolling, but for me this version introduced it. Scrolling doesn't respond to mouse wheel or track pad. Seems to scroll to the right of selected cell but not to the left. Then suddenly corrects itself. Selection of cell with mouse click is also unreliable. Such random behaviour makes libra office unusable until this is fixed. This is a MAJOR bug. It's not just normal. The product is unusable. MAC OS is Ventura 13.6.1 JohnM
resetting to original *earliest* version affected.
(In reply to Stéphane Guillou (stragu) from comment #60) > resetting to original *earliest* version affected. I just looked at my commits and LibreOffice 7.5.9 does not include all of my patches for this bug. I also recently abandoned two other patches in libreoffice-7-5 that affected live resizing since neither got reviewed in a reasonable amount of time so I assumed that libreoffice-7-5 is past its terminal release. If libreoffice-7-5 is still alive, let me know and I'll resubmit my patches to that branch so that they are included in LibreOffice 7.5.10 (LibreOffice 7.6.5 is already set to include all the patches). In the meantime, users should probably be testing with the nightly master builds to get the current state of this bug. LibreOffice 7.5.9 and 7.6.4 are in a "half in/half missing" state compared to the nightly master builds.
(In reply to Patrick Luby from comment #61) > If libreoffice-7-5 is still alive, let me know and I'll resubmit my patches > to that branch so that they are included in LibreOffice 7.5.10 (LibreOffice > 7.6.5 is already set to include all the patches). > > In the meantime, users should probably be testing with the nightly master > builds to get the current state of this bug. LibreOffice 7.5.9 and 7.6.4 are > in a "half in/half missing" state compared to the nightly master builds. Update: here are the list of my patches that are not in LibreOffice 7.5.9 but will be included in LibreOffice 7.6.5: https://gerrit.libreoffice.org/c/core/+/160366 https://gerrit.libreoffice.org/c/core/+/160045 Also, testers can also test the current LibreOffice 24.2.0 beta as that has all of my patches. Not that I expect my patches to fix the original problem on Mac Intel machines. But at least is should be no worse than the "half in/half missing" state in LibreOffice 7.5.9 and 7.6.4.
To re-iteratet: Skia / Metal is fine. Skia / Raster (aka "Force Skia software rendering") is not as fine but still much better than in my last screencast from 2023-11-07 The severe issues documented in screencast 2023-11-04 appear to be resolved. Skia / Raster on intel mac seems ok now: the scrollbar does not move at all while scrolling is in progress. Once scrolling stops it jumps to the correct location instantly. Scrolling by dragging the scrollbar also works better than in the screencast 2023-11-07. Is it fair to call this bug here fixed? I see an overall much improved situation ffor document scrolling on intel mac with skia / raster. The remaining issues should / could be handled in new issues. WDYT, Patrick? attachment: 2023-12-13 first two finger trackpad then scrollbar scrolling Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 22727f590cf0e1c5512f60d47824e78a6cce4c32 CPU threads: 8; OS: macOS 13.6.3; UI render: Skia/Raster; VCL: osx Locale: de-DE (en_DE.UTF-8); UI: en-US Calc: threaded
Created attachment 191406 [details] 2023-12-13 first two finger trackpad then scrollbar scrolling
(In reply to steve from comment #63) > To re-iteratet: Skia / Metal is fine. That is very good to know. I will post this as the first thing to try for people using LibreOffice 7.5.9 or 7.6.4. > The remaining issues should / could be handled in new issues. WDYT, Patrick? I know I resisted closing this bug the other day, but it now makes sense to me to open new issues. I am guessing that the Skia/Raster and two finger scroll bug that you see (I see it a little bit on Mac Silicon) is caused by something different than this bug.
*** Bug 158754 has been marked as a duplicate of this bug. ***
(In reply to Patrick Luby from comment #65) > I am guessing that the Skia/Raster and two finger scroll bug that you see (I > see it a little bit on Mac Silicon) is caused by something different than > this bug. Update: I think I found what is causing the scrollbar to not move until you stop scrolling when using Skia/Raster or Skia disabled: https://gerrit.libreoffice.org/c/core/+/161075 I am posting to this bug because, since it is marked "fixed", users experiencing the "only half of the patches are in LibreOffice 7.5.9 and 7.6.4" most likely won't find this bug. Now I am reluctant to open a new bug for the above patch as I would guess that users will likely confuse any new bug with the existing LibreOffice 7.5.9 and 7.6.4 problems.
*** Bug 158797 has been marked as a duplicate of this bug. ***
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9f92a39234dfae40fe19ab6fa47caf8b21dd8847 Related: tdf#155266 stop delaying painting timer while swiping It will be available in 24.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.
OK. I have committed a fix for the "scrollbar doesn't move while swiping with Skia/Raster and Skia disabled" bug. It should be in tomorrow's (21 December 2023) nightly master build. On my Mac Silicon machine, the scrollbar moves smoothly with Skia/Raster and Skia disabled and performance is similar to Skia/Metal. If anyone can test this fix on Mac Intel with Skia/Raster or Skia disabled, that would be much appreciated: Version: 24.8.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 9f92a39234dfae40fe19ab6fa47caf8b21dd8847 CPU threads: 8; OS: macOS 14.2.1; UI render: Skia/Raster; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded
Created attachment 191543 [details] 2023-12-21 skia raster on intel mac OK.mp4 skia/raster on intel mac: scrolling document is buttery smooth and scrollbar follows document as expected. Patrick: grat work and thanks for not easily giving up, when things get more involved. This issue here is a prime example of a problem that would have probably been sitting untouched for several years despite skia being the default and a degraded default UX. Really glad you managed to fully address this and make scrolling usable again on macOS. see: 2023-12-21 skia raster on intel mac OK.mp4 - document scrolling is good - scrollbar behavior is good 🤩 👌
(In reply to steve from comment #71) > Created attachment 191543 [details] > 2023-12-21 skia raster on intel mac OK.mp4 I am glad to hear that the latest fix works on Mac Intel. I am very interested to know if @Telesto also sees improvement with Skia/Raster on his Mac Intel machine.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/21b6f7f58512a8550fc0afaf2d1984f32b87876a Related: tdf#155266 stop delaying painting timer while swiping It will be available in 24.2.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.
The scrollbar follows document as expected in Writer, nice :-) Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 0cd74b5be297f638d455b9b267462192f2e6620c CPU threads: 8; OS: macOS 13.4.1; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded the but.... * The issue of scrollbar being stuck while swiping persists in Calc * The Skia/Raster performance is still worse on my intel compared to cea165a3ebdb5f2a2b172004ff1b3848f303d78a. Not terrible, but not quick either. Asking myself: Is the fix at comment 22 still needed (or having an advantage) with the fix comment 73 in place?
Sorry for the confusion - my last screencast used skia/metal and not skia/raster. Thus retested and skia/raster scrollbar behavior is improved. The scrollbar is no longer stuck when scrolling document. The behavior is not as smooth as skia/metal. But I guess it is good enough. It would help to unify terminology in settings. Talking about one thing and seeing something different in settings is very annoying. Not only is that confusing but you will also get wrong user feedback (not at all looking at myself 😇).
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/8339bb40b22e9426a05eb1d122cc8ef12ab7a229 Related: tdf#155266 Eliminate delayed scrollbar redrawing when swiping It will be available in 24.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.
(In reply to Commit Notification from comment #76) > Patrick Luby committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > 8339bb40b22e9426a05eb1d122cc8ef12ab7a229 > Working nicely Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 90b12c9bad55e8f50b75a6d7b68caa27d82cc2b9 CPU threads: 8; OS: macOS 13.4.1; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/627d98a64164d117f4fbf8e3055dd2b14d9d7ab6 Related: tdf#155266 Eliminate delayed scrollbar redrawing when swiping It will be available in 24.2.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 "libreoffice-7-6": https://git.libreoffice.org/core/commit/71ddd51f72532cb7f854abbad870a3829ea93d38 Related: tdf#155266 Eliminate delayed scrollbar redrawing when swiping It will be available in 7.6.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.
*** Bug 158926 has been marked as a duplicate of this bug. ***
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/4509eb097d82b84423f8cbba3c9915a9fbe6f691 Related: tdf#155266 stop delaying painting timer while swiping It will be available in 7.6.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.
*** Bug 159139 has been marked as a duplicate of this bug. ***
*** Bug 159159 has been marked as a duplicate of this bug. ***
*** Bug 159231 has been marked as a duplicate of this bug. ***
*** Bug 159224 has been marked as a duplicate of this bug. ***
*** Bug 159304 has been marked as a duplicate of this bug. ***
*** Bug 159345 has been marked as a duplicate of this bug. ***
*** Bug 159357 has been marked as a duplicate of this bug. ***
*** Bug 159361 has been marked as a duplicate of this bug. ***
*** Bug 159354 has been marked as a duplicate of this bug. ***
*** Bug 158650 has been marked as a duplicate of this bug. ***
*** Bug 159820 has been marked as a duplicate of this bug. ***
*** Bug 160266 has been marked as a duplicate of this bug. ***
*** Bug 160177 has been marked as a duplicate of this bug. ***