Bug 50613 - VIEWING: Scrolling performance slow in files with lots of chart objects
Summary: VIEWING: Scrolling performance slow in files with lots of chart objects
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Master old -3.6
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:5.3.0
Keywords: perf
Depends on:
Blocks:
 
Reported: 2012-06-02 05:54 UTC by Ruslan Kabatsayev
Modified: 2017-01-03 20:35 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Test document (23.67 KB, application/vnd.oasis.opendocument.text)
2012-07-16 12:03 UTC, Ruslan Kabatsayev
Details
Sysprof profile when scrolling (78.42 KB, application/x-bzip)
2012-09-11 11:00 UTC, Ruslan Kabatsayev
Details
Another test case (893.45 KB, application/vnd.oasis.opendocument.text)
2013-01-03 20:36 UTC, Ruslan Kabatsayev
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ruslan Kabatsayev 2012-06-02 05:54:23 UTC
How to reproduce:
1. Copy-paste first table from this page http://en.cppreference.com/w/cpp/language/operator_precedence to Writer
2. Press Ctrl+A
2.5. Wait for Writer to select the table (this is first indication of problem)
3. Try to scroll
3.5 See very laggy scrolling
Comment 1 Florian Reisinger 2012-06-02 10:08:34 UTC
No problem with 3.6 alpha (maybe it's too old...)
Comment 2 Joel Madero 2012-07-15 23:37:11 UTC
In order to help us diagnose and fix this problem please upload a document that displays the behavior that you've listed. Marking as NEEDINFO until attachment is uploaded, once it is please set status back to UNCONFIRMED. Thanks!
Comment 3 Ruslan Kabatsayev 2012-07-16 12:03:17 UTC
Created attachment 64271 [details]
Test document

Here it is
Comment 4 Joel Madero 2012-09-04 22:57:20 UTC
Works for me no problem running LibreOffice 3.7.0.0.alpha0+ (Build ID: d801a8f). Because Florian has also confirmed that it works I'm marking this as RESOLVED->WORKSFORME. If you're still experiencing a problem with the latest stable release please reopen as UNCONFIRMED and we'll try to further diagnose it. 

Also please provide additional info about your machine (OS, and computer specs) just in case that helps us. 

Thanks for sticking with this
Comment 5 Ruslan Kabatsayev 2012-09-11 10:36:49 UTC
I guess latest stable is 3.6.1.
I'm still experiencing the problem on:
1. LibO 3.6.1.2 (Build ID: e29a214) on Ubuntu 10.04 LTS on EEEPC 1015PN at least with intel N10 graphics
2. LibO 3.7.0.0.alpha0+ (Build ID: dc44bd) on LFS 6.3 on Core i7 machine with nvidia gtx460 video
The problem only appears when Ctrl+A is pressed with text cursor outside the table. Also, the table should go out of viewport (i.e. get clipped), then the lag is most visible.
Comment 6 Ruslan Kabatsayev 2012-09-11 11:00:43 UTC
Created attachment 66964 [details]
Sysprof profile when scrolling

Here's a sysprof profile if it can help finding source of the problem. I made several scrolls forward & backward, scaled the sheet, seeing the lags, with running sysprof.
Comment 7 Alex Thurgood 2012-10-04 08:53:28 UTC
No problem for me with Version 3.7.0.0.alpha0+ (Build ID: b966a09)
on Mac OSX 10.8.2


Alex
Comment 8 Alex Thurgood 2012-10-04 08:56:53 UTC
No problem with test document either.


Alex
Comment 9 Ruslan Kabatsayev 2012-10-20 11:29:01 UTC
Still reproduces with 3.7.0.0.alpha0+ (Build ID: 370m0(Build:0)).
Also, I can easily reproduce this on (latest) Ubuntu 12.04 with libreoffice from ppa:libreoffice/ppa (Version 3.6.0.2 (Build ID: 360m1(Build:102))) with both intel and nvidia video cards.
Comment 10 Joel Madero 2012-11-01 20:58:17 UTC
No problem here either, 3.6.1.2 as well as Master on Bodhi Linux (based on Ubuntu 12.04)

Marking as WORKSFORME. Please backup your LibO config folder and then delete the folder (not the backup!). See if resetting your user settings corrects the problem. 

If it does, you can attach the user config folder to this bug and reopen as NEW with edited title saying "user configuration results in slow/laggy table scroll" or something similar. 

If it does not fix it, please comment and we'll see what other recommendations we can come up with. Ultimately 3 people cannot reproduce so I suspect it's system specific.
Comment 11 Ruslan Kabatsayev 2012-11-19 20:13:04 UTC
(In reply to comment #10)
> Marking as WORKSFORME. Please backup your LibO config folder and then delete
> the folder (not the backup!). See if resetting your user settings corrects
> the problem. 

Well, it doesn't change anything. Still slow scrolling.
 
> If it does not fix it, please comment and we'll see what other
> recommendations we can come up with. Ultimately 3 people cannot reproduce so
> I suspect it's system specific.

I doubt it's system specific, I have this bug on at least on 3 machines with different CPU&GPU generations and 2 different distributions.
Comment 12 Ruslan Kabatsayev 2012-12-25 20:30:10 UTC
I still can easily reproduce this bug, now on openSUSE 12.2 "Mantis" with default libreoffice installation (LibreOffice 3.5:build-403 Build ID: 350m1(Build:403)).
Thus, I don't think this is system-specific, but rather other testers might have tried this not quite in the same way as I do. I've not seen any system (linux distribution or hardware) on which this bug wouldn't reproduce. Please note additional information to reproduce in comment 5.
As per above, I reopen this bug.
Comment 13 Ruslan Kabatsayev 2012-12-25 21:28:24 UTC
Here's a screen record of how to reproduce this bug: http://www.youtube.com/watch?v=dp9pAKxUwm0
Comment 14 Ruslan Kabatsayev 2013-01-02 23:20:29 UTC
This bug is also visible on Windows machine, though the lags are several times smaller than in Linux. Tested with LibO 3.6.4.
Comment 15 Jorendc 2013-01-02 23:35:27 UTC
I can reproduce that scrolling is slower. It's not THAT slow, but it's slowER. Therefore I mark this bug as NEW.

Tested with Mac OSX 10.8.2; LibreOffice 4.1.0.0.alpha0+ (Build ID: 73731b01cd65defdf9b42a9754bede3ba84221d)
TinderBox: MacOSX-Intel@1-built_no-moz_on_10.6.8, Branch:master, Time: 2013-01-02_08:47:51

Kind regards,
Joren
Comment 16 Ruslan Kabatsayev 2013-01-03 20:36:28 UTC
Created attachment 72478 [details]
Another test case

This test case doesn't need any selection to reproduce the bug. Just open it and try to scroll the document from top to bottom and back (it becomes even slower when you go from bottom to top, especially two upper charts).
Note: this bug is MUCH less visible in Windows and MacOS X than it is in Linux. Funniest thing is that even Windows version run in Wine appears faster than native Linux version.
Comment 17 Owen Genat (retired) 2014-01-10 00:56:08 UTC
I tested attachment 64271 [details] and attachment 72478 [details] under Ubuntu 10.04 x86_64 running:

- v3.3.0.4 OOO330m19 Build: 6
- v3.4.6.2 OOO340m1 Build: 602
- v3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
- v3.6.7.2 Build ID: e183d5b
- v4.0.6.2 Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24
- v4.1.4.2 Build ID: 0a0440ccc0227ad9829de5f46be37cfb6edcf72

In keeping with comment #4, comment #8, and comment #10 attachment 64271 [details] did not exhibit any kind of scrolling lag in any version. I think this bug is therefore essentially about attachment 72478 [details] (chart objects), which in 3.3.0.4 scrolls quite slow, in 3.4.6.2, 3.5.7.2, and 3.6.7.2 is slower again than 3.3.0.4, and in 4.0.6.2 and 4.1.4.2 is noticeably better than all prior listed versions, although still lagging.

Summary amended for clarity. There appears to have been a mild performance improvement.
Comment 18 Joel Madero 2015-05-02 15:44:35 UTC Comment hidden (obsolete)
Comment 19 Ruslan Kabatsayev 2015-05-02 16:34:14 UTC
Still reproduces with 4.4.2.2 on Ubuntu Precise. What's interesting is that if I select only some or all cells of the table in test case 64271, then there're no lags. But when I select the whole document, the lags are present.
Comment 20 Armin Le Grand (CIB) 2016-03-23 09:21:40 UTC
Taking a look...
Comment 21 Armin Le Grand (CIB) 2016-03-23 11:14:21 UTC
More looking at the sample doc from comment 16, the charts have fat lines, these are currently not really fast drawn on linux systems. Not sure about the table stuff, need to take a 2nd look later.
Comment 22 Armin Le Grand (CIB) 2016-03-24 09:14:40 UTC
Also slow: using chart helper to get the primitives from the chart is good, but then should be buffered e.g. at the SwOLEObj...
The load of the chart itself and 1st creation makes initial showing slow, but at least only shown charts (visible directly after load). Checked with zooming out and saving a copy of this one.
Checked that the charts are saved containing a preview in the ODF in ReplacementObjects. These are just Metafiles, but could potentially be used to fasten load and 1st rendering more. This would need a combination of first using that (if available), setting up LoadInTheBackground, invalidate when available, all the dependencies and secure lifetime/messaging.
Comment 23 Commit Notification 2016-07-07 20:35:14 UTC
Armin Le Grand committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=cb382034b061b4acd4f0fd490f42af34517a7b8d

tdf#50613 speedup fat line drawing on linux using cairo

It will be available in 5.3.0.

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 24 Commit Notification 2016-07-07 20:35:18 UTC
Armin Le Grand committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=30fdc46969f3c90c47cddf18d0dde640c8ea280e

tdf#50613 add close_path to correctly show closed polygons

It will be available in 5.3.0.

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 25 Commit Notification 2016-07-07 20:35:22 UTC
Armin Le Grand committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=64e1113916a6b19b30f95b454018528571ac84df

tdf#50613 buffer OLE primitives for charts

It will be available in 5.3.0.

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 26 Commit Notification 2016-07-07 20:35:33 UTC
Armin Le Grand committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9f0766917a4fb1bc8fe1786c3b46132dd63c1c66

tdf#50613 add support to load charts asynchronously

It will be available in 5.3.0.

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 27 Commit Notification 2016-07-07 20:35:37 UTC
Armin Le Grand committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=68e8d075d92ae4002898a4665a9d7c50162c2511

sw: tdf#50613 fix waitFinished into a loop

It will be available in 5.3.0.

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 28 Commit Notification 2016-07-07 20:35:41 UTC
Armin Le Grand committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3dc8ee7d8eec40093af5df3113ef226bc59220ff

sw: tdf#50613 fix async chart load handling

It will be available in 5.3.0.

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 29 Commit Notification 2016-07-07 20:36:04 UTC
Armin Le Grand committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=63ed9d7f5b75f35ae49396de0c5f6a3216c494e1

Related: tdf#50613 use an own instance of ThreadPool

It will be available in 5.3.0.

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 30 Xisco Faulí 2016-09-26 10:16:02 UTC
Hello Armin,
Is this bug fixed?
If so, could you please close it as RESOLVED FIXED?
Comment 31 Ruslan Kabatsayev 2017-01-03 20:35:51 UTC
The performance in 5.3.0.0.beta2 is somewhat better, but it still is suboptimal: on my Core i7-4765T with GeForce GTX 750 Ti I have about 2 FPS when scrolling the test case.