Created attachment 102616 [details] The spreadsheet that displays the problem. Problem description: When a large spreadsheet (a few thousands of rows) with a graph is opened CPU (a single core) gets 100% loaded and UI is unresponsive. This is apparent when the graph is visible; it looks like the graph is redrawed all the time). Steps to reproduce: 1. Open the attached document. and try to navigate it - switch between tabs, scroll the spreadsheets, etc. Current behavior: UI is unresponsive, I have to wait up to several minutes before the application reacts to my actions. Expected behavior: The interface should be more responsive. The graph images can be cached internally to optimize performance. The drawing itself can be optimized (e.g. draw an approximate version with a reduced number of points and then gradually update it to be more precise). Operating System: Ubuntu Version: 4.2.4.2 release
I see no issue at all using LibO 4.2.5.2 under Win7x64 try upgrading to that version, if it's not enough try also resetting the user profile ( https://wiki.documentfoundation.org/UserProfile ) if issue persist it's probably a Linux specific issue
Confirmed with libreoffice 3.6.7, 4.2.5.2 and 4.3.0.2, ubuntu 14.04 x86. There is a serious lag/delay when scrolling near the charts. The lag may be because Calc is trying to refresh the chart when scrolling. I agree with Andrey that Calc should do sth to optimize the performance regarding charts. When the cell data are not changed, or the user did not change the chart layout, the chart will always remain the same, so there is no need to refresh/update the chart when scrolling or switching bewteen sheets. Only when the cell values are changed or the user change the chart layout, shall the chart be updated. (Maybe a cached image file can be used? As you can see if you insert an image in a spreadsheet, you can scroll very fast)
** 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.1 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-07-18
I tried the attached spreadsheet with version 4.4.2.2 Build ID: 40m0(Build:2) (the one in Ubuntu 15.04). Scrolling with (partially) visible graph seems faster now, although slightly sluggish still. I'd say scrolling is acceptable. However, when I tried to resize the graph the UI froze for a few minutes with 100% load of one CPU core. It also affected DE performance (which is currently XFCE 4.12) - the mouse cursor changed to the one that is displayed when you resize windows and it didn't change back to normal even when I switched to another application; it also appeared as if other applications were not responsive to mouse actions. After some time DE restored its functionality, while Calc was still loading the CPU. I don't remember such problems back when I reported this bug, so it looks like a regression. Keeping this bug open as resizing performance is unacceptable.
@Andrey we should not mix different things in the same bug report... the original problem (according to comment 0) was UI unresponsivness which you don't see anymore, right? if yes, please set status to RESOLVED WORKSFORME then please upgrade to latest 4.4.4.3 or 4.4.5.2rc release and retest the resize problem (which I don't reproduce on Win7x64) if that persists please file a new clean report about that @Kevin would you please retest as well? set status to NEEDINFO waiting 4 users feedback
@tommy27 No, the UI is unresponsive when the graph is resized, and I qualify it as part of the original problem. The bug is not resolved for me, please don't close it. To me, the bug can be closed when operating with the graph in the attached spreadsheet does not cause severe UI performance degradation. The earlier posts indicate that the problem didn't reproduce on Windows but only on Linux.
what I tried to say is that probably there were 2 issues first one, unresponsiveness while scrolling at full size, which seems fixed now... you saw it with older releases and not with latest? and now unresponsiveness during resizing which you see now with newer releases and did not notice in older ones. so these are 2 different issues... It's better to close this one "the scrolling unresponsiveness" and open a new one about the "resizing unresponsiveness" it would be easier for developers to focus on the actual problem rather than with somewhat that is different from the original description
(In reply to tommy27 from comment #7) > what I tried to say is that probably there were 2 issues > > first one, unresponsiveness while scrolling at full size, which seems fixed > now... you saw it with older releases and not with latest? > > and now unresponsiveness during resizing which you see now with newer > releases and did not notice in older ones. > > so these are 2 different issues... The original behavior was unresponsiveness caused by constant redraws. This happened in different contexts, including scrolling and resizing. Now redraws don't seem to happen during scrolling but redrawing during resize is unacceptably slow. I realize that something changed but I can't say the change solves the problem. The problem persists, and that's why I believe the bug should stay open. I don't know the internals of the implementation and whether the current behavior is caused by a different issue in the code. The developers are free to update the description or comment or create a sub-issue that gives a more technical description.
one more information... is the issue limited to .xls or happens even if you save that file as .odt or .xlsx ? I can't test it myself since the issue only affects Linux and not Windows
(In reply to tommy27 from comment #5) Well, let's focus the bug as originally reported: > Steps to reproduce: > 1. Open the attached document. and try to navigate it - switch between tabs, scroll the spreadsheets, etc. I open the attachment with LibreOffice Version: 5.0.0.3, scrolling the spreadsheet, switch between tabs, changing the cell values etc. No delay. --> WORKSFORME. For the issue regarding resizing the chart, we should file a new clean bug report. (I will try to file it later)
(In reply to Kevin Suo from comment #10) Sorry forgot to mention the version: Version: 5.0.0.3 Build ID: f79b5ba13f5e6cbad23f8038060e556217e66632 Locale: zh-CN (zh_CN)
(In reply to Kevin Suo from comment #10) Ops..Sorry, I should test this on Linux, as this bug was reported on Linux. Set back to NEEDINFO as I don't have a Linux machine at this moment. Sorry for the noise.
don't worry Kevin please also try other file extensions (see comment 9) if your findings are confirmed a clean new report would be much better than insisting on the current one
(In reply to tommy27 from comment #9) > one more information... > is the issue limited to .xls or happens even if you save that file as .odt > or .xlsx ? I tried saving the file to .ods, restarting Calc and opening the .ods file. Resizing the graph still blocks UI for a long time.
thanks 4 feedback. now we know the big is not extension specific
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of FDO Message generated on: 2015-09-03