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
No problem with 3.6 alpha (maybe it's too old...)
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!
Created attachment 64271 [details] Test document Here it is
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
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.
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.
No problem for me with Version 3.7.0.0.alpha0+ (Build ID: b966a09) on Mac OSX 10.8.2 Alex
No problem with test document either. Alex
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.
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.
(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.
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.
Here's a screen record of how to reproduce this bug: http://www.youtube.com/watch?v=dp9pAKxUwm0
This bug is also visible on Windows machine, though the lags are several times smaller than in Linux. Tested with LibO 3.6.4.
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
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.
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.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.2 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-05-02
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.
Taking a look...
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.
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.
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.
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.
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.
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.
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.
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.
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.
Hello Armin, Is this bug fixed? If so, could you please close it as RESOLVED FIXED?
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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1cf1e9cc33327128f30c6781b4d8c16e20601540 crashtesting: export of fdo50613-3.odt to docx crashes It will be available in 6.5.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.