Clicking the RTL control for cell format for a large number of cells makes calc unresponsive. Working on CENTOS 6.4 fully updated.
Steps to reproduce:
1. Choose a small number of cells
2. Click the RTL cell format control is OK
3. Choose the whole worksheet (top leftmost cell, before the A1)
4. Click the RTL cell format control, and calc becomes unresponsive
I guess calc is just taking along time to process the request when a very large number of cells is involved.
The bug was not present in previous versions. I would know as I work in RTL mode quite frequently.
Operating System: Linux (Other)
Version: 22.214.171.124 release
Broken between 4e3e171262aed0e52fa76158950d5be770249e80..9cd7f7aded9ba171bf91a8223e6e8a868aedd792
regression due to 706e3b8e43df94310b2fe8458da67875073a046c "fdo#63546: set appropriate alignment when wrt direction of cells is changed"
Well, its clear why its slow, its iterating over every cell. Is there a common pattern in calc to handle these all-cells cases.
(In reply to comment #3)
> Well, its clear why its slow, its iterating over every cell. Is there a
> common pattern in calc to handle these all-cells cases.
Yes, I was not aware this is a particular occurence, ie, "all-cells". It does not happen in other cases such as changing "all-cells" background to yellow, or setting borders in all cells, or changing font. Only with RTL direction setting it happens.
Iterating like that through all the cells is wrong. This needs some improvements to make use of the data structures used for storing cell attributes.
Actually we should have a method that applies the formatting to a whole range alredy which should be the better solution.
Argh.. ScFormatShell is the wrong place anyway to handle it, these modifications should be done through ScTabViewShell instead, like all other requests of ScFormatShell are forwarded through that.
Unfortunately it's not just applying an attribute, but applying it conditionally. This might mean having to implement a whole new chain of function set handling this special case, through ScViewFunc, ScDocFunc, ScDocument, ScTable, ScColumn, which then could take advantage of applying the attribute to a block of rows instead of slicing and merging the attribute array for every row.
Reverted all changes related to bug 63546 on master.
So, with the removal of the problematic code in master this performance problem should be gone there, but still remains in 4-1.
Question is, should we revert it also there for 4.1.4 and thus remove the fix of bug 63546 given that implementation wasn't what actually might be needed?
Pending review for 4-1 as https://gerrit.libreoffice.org/6691
(In reply to comment #9)
> So, with the removal of the problematic code in master this performance
> problem should be gone there, but still remains in 4-1.
> Question is, should we revert it also there for 4.1.4 and thus remove the
> fix of bug 63546 given that implementation wasn't what actually might be
Will be very happy to check - it will be available in 4.1.4 or can a pre-master compiled X64 linux version be downloaded somewhere ?
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":
resolved fdo#70750 reverted inappropriate implementation of fdo#63546
It will be available in LibreOffice 4.1.4.
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:
Affected users are encouraged to test the fix and report feedback.
(In reply to comment #11)
> Will be very happy to check - it will be available in 4.1.4 or can a
> pre-master compiled X64 linux version be downloaded somewhere ?
Dailies are available under http://dev-builds.libreoffice.org/daily/ an x86_64 under http://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@46-TDF/