Bug 62229 - Formatting : CPU fully committed - change of cell format
Summary: Formatting : CPU fully committed - change of cell format
Status: RESOLVED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: x86 (IA32) Linux (All)
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-12 12:47 UTC by Kobus
Modified: 2015-02-11 19:56 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kobus 2013-03-12 12:47:54 UTC
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.
Comment 1 Petr Mladek 2013-03-14 16:07:52 UTC
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.
Comment 2 QA Administrators 2013-09-24 02:01:05 UTC
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
Comment 3 Kobus 2013-09-28 15:17:49 UTC
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
Comment 4 Kobus 2013-09-28 15:37:11 UTC
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.
Comment 5 Joel Madero 2014-11-06 18:04:29 UTC
Needs to be confirmed by QA - moving to UNCONFIRMED. Thanks!
Comment 6 A (Andy) 2014-11-06 20:50:34 UTC
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?
Comment 7 QA Administrators 2015-02-11 19:56:56 UTC
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-02-11