Bug 75665 - Calc/Spreadsheet, long multiline text in the cells, lagging - almost hanging when scrolling over sheet's content
Summary: Calc/Spreadsheet, long multiline text in the cells, lagging - almost hanging ...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.2.0.4 release
Hardware: All Linux (All)
: highest minor
Assignee: Not Assigned
URL:
Whiteboard: target:4.3.0 target:4.2.5
Keywords: bibisectNotNeeded, regression
Depends on:
Blocks: mab4.3
  Show dependency treegraph
 
Reported: 2014-03-02 10:09 UTC by 8472
Modified: 2015-12-17 07:51 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
example showing the issue (370.07 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-03-02 10:09 UTC, 8472
Details
attaching the example again (in ZIP this time), as the prev. seems to be somehow broken after upload (73.64 KB, application/zip)
2014-03-02 10:14 UTC, 8472
Details
callgrind data (298.23 KB, application/x-xz)
2014-04-15 19:29 UTC, Kohei Yoshida
Details
callgrind data (543.42 KB, application/x-xz)
2014-04-16 02:49 UTC, Kohei Yoshida
Details

Note You need to log in before you can comment on or make changes to this bug.
Description 8472 2014-03-02 10:09:47 UTC
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.
Comment 1 8472 2014-03-02 10:14:25 UTC
Created attachment 94957 [details]
attaching the example again (in ZIP this time), as the prev. seems to be somehow broken after upload
Comment 2 m.a.riosv 2014-03-02 20:02:37 UTC
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
Comment 3 8472 2014-03-03 10:20:28 UTC
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.
Comment 4 m.a.riosv 2014-03-03 10:56:44 UTC
Then we change the status to unconfirmed, waiting someone can confirm it in Linux.
Comment 5 Chris 2014-03-04 11:21:08 UTC
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.
Comment 6 Joel Madero 2014-03-07 04:37:21 UTC
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
Comment 7 Kohei Yoshida 2014-04-15 17:25:53 UTC
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.
Comment 8 Kohei Yoshida 2014-04-15 19:21:59 UTC
HbLayoutEngine::layout() spends 87% of the total rendering time, of which 56% is spent on hb_shape().
Comment 9 Kohei Yoshida 2014-04-15 19:29:42 UTC
Created attachment 97423 [details]
callgrind data

Here is what my callgrind data shows, with 87% spent in HbLayoutEngine::layout().
Comment 10 Kohei Yoshida 2014-04-16 01:39:59 UTC
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?
Comment 11 Commit Notification 2014-04-16 01:43:14 UTC
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.
Comment 12 Kohei Yoshida 2014-04-16 02:42:11 UTC
I'll park this on me for now.
Comment 13 Kohei Yoshida 2014-04-16 02:49:25 UTC
Created attachment 97440 [details]
callgrind data

New callgrind data after the initial change.
Comment 14 Kohei Yoshida 2014-04-16 03:05:01 UTC
Oh BTW

(In reply to comment #5)

> The problem is related to bug 68961.

No it is not.  This one is unrelated.
Comment 15 Commit Notification 2014-04-16 15:42:28 UTC
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.
Comment 16 Commit Notification 2014-04-17 00:08:37 UTC
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.
Comment 17 Kohei Yoshida 2014-04-17 00:11:32 UTC
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.
Comment 18 Joel Madero 2014-04-21 14:54:06 UTC
@Kohei - would a bibisect help here since it appears it's a regression?
Comment 19 Kohei Yoshida 2014-04-21 14:56:26 UTC
(In reply to comment #18)
> @Kohei - would a bibisect help here since it appears it's a regression?

No, not really.
Comment 20 Kohei Yoshida 2014-07-28 19:44:29 UTC
I think Caolan fixed (or reverted my commits, rather) on master to fix this.  Let's see how that helps on the master branch.
Comment 21 Joel Madero 2014-08-08 03:36:06 UTC
Can we close this as RESOLVED-FIXED?
Comment 22 8472 2014-08-08 17:00:09 UTC
(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.
Comment 23 Robinson Tryon (qubit) 2015-03-05 20:43:36 UTC
(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.
Comment 24 Robinson Tryon (qubit) 2015-03-31 16:46:02 UTC
(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!
Comment 25 tommy27 2015-06-23 10:08:33 UTC
@8472
would you please retest with latest 4.4.3.2 release or with a 5.x master build?
Comment 26 8472 2015-06-24 14:45:45 UTC
(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.
Comment 27 tommy27 2015-06-24 14:56:45 UTC
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"
Comment 28 Robinson Tryon (qubit) 2015-12-17 07:51:59 UTC
Migrating Whiteboard tags to Keywords: (bibisectNotNeeded)
[NinjaEdit]