Bug 165624 - Limit of 200 lines in the code for RowOptimalHeight
Summary: Limit of 200 lines in the code for RowOptimalHeight
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.4.4.2 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Regressions-row-height
  Show dependency treegraph
 
Reported: 2025-03-07 07:34 UTC by Ilya
Modified: 2025-05-27 10:29 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
the problem is starting from line 202 (23.48 KB, application/vnd.oasis.opendocument.spreadsheet)
2025-03-07 07:36 UTC, Ilya
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ilya 2025-03-07 07:34:59 UTC
Description:
In the task https://bugs.documentfoundation.org/show_bug.cgi?id=124098 fixed by specifying a limit of 200 lines in the code:

if (bHasRowOptimalHeight && nCurrentRow > 200) {
  rRecalcRanges.at(nSheet).maRanges.setFalse(nFirstRow, nCurrentRow);
} else {
  rRecalcRanges.at(nSheet).maRanges.setTrue(nFirstRow, nCurrentRow);
}

Because of this, when opening files with a large number of lines, the height changes only for the first 200 lines. 
Is it possible to set this limit in the parameters so that it can be changed manually by users?

Steps to Reproduce:
1. Open a file (*.ods) containing more than 200 lines

Actual Results:
the "RowOptimalHeight" parameter is used only for the first 200 rows

Expected Results:
The "RowOptimalHeight" parameter can be configured


Reproducible: Always


User Profile Reset: No

Additional Info:
The "RowOptimalHeight" parameter can be configured manually through the parameters and specify a limit.
Comment 1 Ilya 2025-03-07 07:36:44 UTC
Created attachment 199673 [details]
the problem is starting from line 202
Comment 2 Buovjaga 2025-03-07 09:37:20 UTC
Let's ask Balázs what he thinks.
Comment 3 V Stuart Foote 2025-03-07 13:22:00 UTC
Reminds me we'd done similar for bug 72125 [1] when populating the expert configuration dialog and bug 109158 populating the autocorrect dialog. But that caused complaints about formatting with listings over the 100 count bug 99071 [2]. 

Admittedly that was for the UI rather than document canvas, performance hit came from doing pixel perfect calculations of the text strings, height and width.

The best performance was with capped count of entries. But worked around by generalizing the width/height calcs, or incrementally exposing the list as needed.

For the calc sheet rows we either need pixel perfect rendering of height and width, especially when a printer is involved.

But for performance of opening and calculations while working, the user should have the option to ignore row heights string widths.

And that is where we arrived for bug 124098 and its expert config value of "RecalcOptimalRowHeightMode" [3] which gives the users control, but not well known and the default is set to 'Recalc always' for "least surprise", though for performance it maybe should be 'Recalc never'? But that might be to extream for folks used to pixel perfect cells on their sheets.



[1] https://cgit.freedesktop.org/libreoffice/core/commit/?id=62ea355b2679073b8ee326df5793231996136da9
reverted for bug 99071 with
[2] https://gerrit.libreoffice.org/c/core/+/39951
[3] https://gerrit.libreoffice.org/c/core/+/163421
Comment 4 V Stuart Foote 2025-03-07 13:28:50 UTC
(In reply to V Stuart Foote from comment #3)

Point being, setting the cap on the rows receiving an *optimal row height* is performant, but already have a user expert config and an entry in the UI

Tools -> Options -> Calc -> Formula panel as 'Optimal row height' lb.

Though it might do better, be more discoverable, on the Calc -> View panel?
Comment 5 Justin L 2025-03-07 14:15:41 UTC
(In reply to Ilya from comment #0)
> if (bHasRowOptimalHeight && nCurrentRow > 200) {
This is referring to https://gerrit.libreoffice.org/c/core/+/141204
which was backported to 7.4.4.
Comment 6 Heiko Tietze 2025-03-09 09:08:58 UTC
Making the hard-coded constant 200 a variable expert option would be an easyhack.
Comment 7 V Stuart Foote 2025-03-09 12:45:39 UTC
(In reply to Ilya from comment #0)
> 
> Expected Results:
> The "RowOptimalHeight" parameter can be configured
> 

(In reply to Heiko Tietze from comment #6)
> Making the hard-coded constant 200 a variable expert option would be an
> easyhack.

Sure OK, but the optimization is already in place when rows are being recalculated. Don't do it for sheets above 200 rows. Or a user can elect to not recalculate at all by expert config stanza or UI, with RecalcOptimalRowHeightMode as 'Recalc never'.

So enhancement is for user to recalc optimal heights for sheets with more than 200 rows? By ability to tweak profile to adjust recalc to some number or rows different than 200.

And guess expert config should allow them to set threshold less than or greater than the hardcoded 200.
Comment 8 Ilya 2025-03-12 09:30:47 UTC
> And guess expert config should allow them to set threshold less than or
> greater than the hardcoded 200.

yes, the user should be able to manually adjust the row limit, or disable this limit completely (under his responsibility on large files)
Comment 9 Balázs Varga (allotropia) 2025-03-13 14:05:07 UTC
(In reply to Heiko Tietze from comment #6)
> Making the hard-coded constant 200 a variable expert option would be an
> easyhack.

Make sense to me as well. The user should be able to manually adjust the row limit (probably in the expert config), but we have to consider the other setting as well at Options -> LibreOffice Calc -> Formula -> Recalculation on File Load -> Optimal row height -> Always/Never/Prompt user
Also the default value should be something close to 200 otherwise we will have again very slow loadings in default mode and the users will complain again.