Created attachment 94956 [details] example showing the issue Having a long multiline text in the cells (see the attachment), causes lagging - almost hanging the process when scrolling over sheet's content. After scrolling is finished, operations in the app. are back to normal. No special formatting of the cells is required. Simply create similar multiline content in one cell, and copy/duplicate it in e.g. A1:Z1999. Afterwards try to scroll in that sheet's content. First noticed after upgraded to the new ver. 4.2.*. CPU usage is normal when scrolling and the lagging is shown, nothing what would show an increased CPU utilization. Having Quad-core CPU and 8GB of RAM on the laptop. Have tested it on Arch and Debian Linux distributions so far, problem happened on all of them. Assuming, that this problem would be OS independent.
Created attachment 94957 [details] attaching the example again (in ZIP this time), as the prev. seems to be somehow broken after upload
Hi dv.underworld, thanks for reporting. I can't reproduce with: Win7x64Ult, i34Gb Version: 4.2.0.4 Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71 Please verify if disabling 'Automatically checks spelling', change anything. if not try resetting the user profile, sometimes solves strange issues. https://wiki.documentfoundation.org/UserProfile
Hi, Windows: Have tested it further, and Windows OS appears seems to be affected very little, if at all. I have one virtualized (VirtualBox) Win7 32bit (2CPU core and 1GB RAM) for such testing purposes. Have downloaded there portable LO 4.2.1, and opened the same example https://bugs.freedesktop.org/attachment.cgi?id=94957 file I provided here. The scrolling lagging has appeared very little, and if it did, I presume it was due to low RAM the VM has available. Thus no wonder, that you couldn't reproduce it on more powerful Win7 of yours. Linux: So it seems, that Linux LO installations are affected mostly. I checked your suggestions "disabling Automatically checks spelling" (which I found I had it disabled already anyway) or profile reset (stored in "~/.config/libreoffice/"), but neither of these helped. My additional platform details I tested it with: - PC, Arch Linux 64bit, Dual core CPU 2.4GHz, 3GB RAM, (OpenBox VM), (latest LO ver. 4.2.1 installed via AUR libreoffice-rpm package) - Laptop, Arch Linux 64bit, Quad core CPU 2.5GHz, 8GB RAM, (OpenBox VM), (latest LO ver. 4.2.1 installed via AUR libreoffice-rpm package) - Laptop, Debian Linux 32bit, Dual core CPU 2GHz, 2GB RAM, (LXDE VM), (latest LO ver. 4.2.1 installed from official Debian package taken from homepage) - All of these have latest updates installed. Testing observations: - as was already said, "disabling Automatically checks spelling" doesn't seem to have any effect. - profile reset (stored in "~/.config/libreoffice/"), even if I removed/renamed this whole directory, had either no effect. - when the LO app. window size is resized to smallest possible size, the problem ain't that critical, therefore make sure, that when testing it, you have e.g. maximized the LO app. window, this way the problem should show itself as reported (doesn't matter if it's laptop smaller display or larger e.g. 24" screen). Further confirmations from another Linux users would be great.
Then we change the status to unconfirmed, waiting someone can confirm it in Linux.
I confirm with Debian (7.4). LO 4.2.0.4 (Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71) and LO 4.2.2.1 The problem is related to bug 68961. Kohei fixed this bug in Windows but Linux (and maybe OSX) has still problem with scrolling/viewing performance in spreadsheet.
Thank you for reporting this issue! I have been able to confirm the issue on: Version: 4.3.0.0.alpha0 Date: Tue Feb 25 19:58:48 2014 +0100 Platform :Ubuntu 13.10 DE: GNOME3 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + As I've been able to confirm this problem I am marking as: New (confirmed) Minor - not preventing high quality work but can slow it down Highest - regression + quite noticeable Keywords - regression (checked with bibisect40 and it worked smoothly) P.S. I know it was set as "major" - major bugs are data loss and crashes but "highest" + regression means that it is appropriately triaged. Thanks! + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link: https://wiki.documentfoundation.org/QA/BugTriage and join us on freenode at #libreoffice-qa There are also other ways to get involved including with marketing, UX, documentation, and of course developing - http://www.libreoffice.org/get-help/mailing-lists/. Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
It appears that calculating text geometry with HarfBuzz is very expensive, and that's what's causing this drag during scrolling. Whether it's possible to speed up HarfBuzz's text width calculation, I have no idea yet.
HbLayoutEngine::layout() spends 87% of the total rendering time, of which 56% is spent on hb_shape().
Created attachment 97423 [details] callgrind data Here is what my callgrind data shows, with 87% spent in HbLayoutEngine::layout().
Shortening the string to pass to HarfBuzz in case of text truncation halves the rendering time, but still much slower than 4.1. Now, 80% is spent on hb_shape() from HarfBuzz. Not sure if there is anything I could do on Calc's side. @Khaled Hosny: any idea whether we could speed things up in Harf Buzz's glue code?
Kohei Yoshida committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=087a79db1272858f107656c5ca3c6efb45680986 fdo#75665: Truncate string when clipped on screen. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I'll park this on me for now.
Created attachment 97440 [details] callgrind data New callgrind data after the initial change.
Oh BTW (In reply to comment #5) > The problem is related to bug 68961. No it is not. This one is unrelated.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=21fc47e115530780ad45ae64e8076dc5e9fedb5e fdo#75665: Fix the right-aligned case. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4321ca5a3ca78e4a6e6c3654dbab825036bb60e3&h=libreoffice-4-2 fdo#75665: Truncate string when clipped on screen. It will be available in LibreOffice 4.2.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This commit should help speed it up a bit. I won't close it yet though. I need to come back to this to try some more.
@Kohei - would a bibisect help here since it appears it's a regression?
(In reply to comment #18) > @Kohei - would a bibisect help here since it appears it's a regression? No, not really.
I think Caolan fixed (or reverted my commits, rather) on master to fix this. Let's see how that helps on the master branch.
Can we close this as RESOLVED-FIXED?
(In reply to comment #20) > I think Caolan fixed (or reverted my commits, rather) on master to fix this. > Let's see how that helps on the master branch. (In reply to comment #21) > Can we close this as RESOLVED-FIXED? Unfortunatelly I don't see there any improvement on Linux with the new 4.3.0. Tested on fresh installation of Debian 7.6 (amd64), installed LO 4.3.0 x86-64, using the same attachments I provided here before for testing, but don't see there any difference when scrolling, it's still lagging/hanging the LO window until the scroll is completed, only then I can continue again.
(In reply to Kohei Yoshida from comment #19) > (In reply to comment #18) > > @Kohei - would a bibisect help here since it appears it's a regression? > > No, not really. Whiteboard -> bibisectNotNeeded Changing status from ASSIGNED -> NEW, as no one is currently assigned to this bug.
(In reply to Joel Madero from comment #6) > As I've been able to confirm this problem I am marking as: > Highest - regression + quite noticeable Joel: Please assign this to a MAB, or change priority to 'high'. Thanks!
@8472 would you please retest with latest 4.4.3.2 release or with a 5.x master build?
(In reply to tommy27 from comment #25) > @8472 > would you please retest with latest 4.4.3.2 release or with a 5.x master > build? Tested on 4.4.3.2 in my Arch Linux. - On here provided example file - perfect (tested on 6-7 years old PC (2 CPU Cores & 3GB RAM)). - I also tested it on one my file (with private data), which is more complex, has lot of data & functions inside - this one needs few seconds (tested on laptop with 4 CPU cores & 8 GB RAM) to realize what's happening (even after each scroll to another page needed few secs), but basically it's also much better than it was at the beginning. On smaller LO window it's faster of course than on full 1920x1200 screen. Here, I managed to clear my private data out of it, substituted it with random data, but couldn't get it compressed under 4MB, so I rather stored it in here: http://ulozto.net/xoPQtRzx/big-example-ods-zip Summary, splendid work so far, further improvements will be welcomed.
nice to hear that. so let's close this as RESOLVED WORKSFORME if you have residual issues about different file please open a new clean bug report and put the current one under "see also"
Migrating Whiteboard tags to Keywords: (bibisectNotNeeded) [NinjaEdit]