Running Ubuntu 12.04 LTS with latest upgrades and Gnome (4 Core /2 Threads / Core) Since 3.6 formatting of cells may result in CPU being fully committed to doing NOTHING for at least 5 seconds. Same spreadsheet used under Win8 Calc 3.2 works perfectly. Random occurrence : when selecting cell (without range select) and change background colour OR Bold face OR Italics etc. using toolbar buttons will send the committed CPU Core running @ 100%, interrupting further activity, for some time (at least 5 sec but sometimes up to 7 sec). There is NO way in forcing replication of the error. Highly interruptive and annoying working on even Calc 4.0 on uBuntu 12.04 LTS. Exactly same worksheet on Win8 Calc 3.2 works without interruption - suspect OS issue ??? Or maybe hanging 10 from Gnome the problem? What is the point of all the bells and wistles which only few OMG people use? What about a stable version stripped of all complications and improving from there.
Kobus, do you use the official TDF build from http://www.libreoffice.org/download or some Ubuntu-specific build from Ubuntu repositories, please? You say that problem is random. So, it is hard to reproduce. Such problems are usually even harder to fix. It might help a lot if you attach the problematic document, so we could do tests with it. Could you please attach it? Regarding the bells and whistles. They are produced by the operating system. LibreOffice could not do anything about it. So, here is not the right place to complain about them :-) My suspicion is that you use Ubuntu build with enabled the experimental GNOME4 integration. If this is the case, it might help to disable it. You might try to run the application by: OOO_FORCE_DESKTOP=none libreoffice Does this help you please? Finally, the bug looks random, specific to a particular document, most likely related to Ubuntu-specific build. I understand that it is vary annoying but it can't block the further bug fix releases with other useful fixes and improvements => reducing severity a bit.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team
I have recently upgraded to Version: 4.1.1.2 Build ID: 7e4286b58adc75a14f6d83f53a03b6c11fa2903 The same annoying problem persists, progressively worse than before. When submitting a bug it is hard to imagine the state of mind of the person reading the post. Obviously, one would attempt to be as desriptive as possible, but cannot guarantee the reader would interpret the text with same accurancy as intended. The issue is about FORMATTING. So it about the WYSIWYG of cell content display. Irrespective of the cell containing a simple value or a very complex formula, if the cell contents does not change, the issue is restricted to the redraw of the cell content on a canvas of some type. Between the changing of the WYSIWIG formatting of the cell and the redraw of the changed FORMATTING
I have recently upgraded to Version: 4.1.1.2 Build ID: 7e4286b58adc75a14f6d83f53a03b6c11fa2903 The same annoying problem persists, progressively worse than before. When submitting a bug it is hard to imagine the state of mind of the person reading the post. Obviously, one would attempt to be as desriptive as possible, but cannot guarantee the reader would interpret the text with same accurancy as intended. The issue is about FORMATTING. So it about the WYSIWYG of cell content display. Irrespective of the cell containing a simple value or a very complex formula, if the cell contents does not change, the issue is restricted to the redraw of the cell content on a canvas of some type. Between the changing of the WYSIWIG formatting of the cell and the redraw of the changed FORMATTING, there seems to be a very superlative and lengthy processing going on. What I have noticed also, is that similar type behaviour (over committing the CPU for no apparent reason) when working with graphs (BUT ONLY) when leaving the graph for cell input. (THUS, if graph is in edit mode, leaving edit mode by clicking on a cell outside of the graph area). To get past this annoying nonsense, it is faster to save, close and reopen, than what it is to continue working because the problem would become progressively worse. THE LAY MAN INTERPRETATION : The undo-redo history affects the performance of submitting a changed graph. The very same workaround helps in the case of FORMATTING. (SAVE, CLOSE, RE-OPEN) My comments about bells and wistles are not aimed at the operating system. Since 3.2 there was a concerted effort in competing with other known systems that like to boast. Trying to living it up with the Jones's have resulted in bloated software with no good reason. For instance, what is the purpose of having 1024 number of sheets with 1024 columns and million lines????? To fill one sheet with all columns and 500 000 rows with a "1" would make the spreadsheet "crashing". WHAT IS THE USE??? A high performing spreadsheet without belss and wistles, is exponentially better than all the "cool" stuff on 1/10 of one sheet. The above scenario also applies to FORMATTING. If the simple formatting (changing background colour of one cell) is impeded by architecture required by more advanced formatting, then it would be better to go for only the rudementary formatting. This is not a superficial problem, it is a REAL problem. When calculating numbers, and the rudementary formatting is only used to assist in making sense of the calculation process, and the formatting frustrates the calculation, it is like tail wagging the dog I would love to emulate this problem, but for obvious reasons, it would be difficult to do. HOWEVER, knowing the architecture and realizing that what is being said here accurs between "COMIT CHANGE" and "REDRAW" you might suggest a procedure that I can follow that might emulate the problem predictably.
Needs to be confirmed by QA - moving to UNCONFIRMED. Thanks!
Referring to the comment from Petr, does this happen only with a specific file or can you reproduce with another, new file, which you could maybe attach or give detailed information to reproduce it? There was no confirmation yet and as Petr mentioned it is probably very difficult to reproduce without a test file and detailed reproducible test procedure and because the problem seems to be random. I suppose you have this problem still?
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.