Description: SUMMARY(EDITING,UI): A plain, simple, default spreadsheet containing only numbers can be caused to turn sluggish, create delays, and print (briefly,repeatedly) "adapt row height" messages at bottom of screen (with green progress bar) everytime activity occurs. REPLICATION (using LibreCalc v7.1.5.2 x86 on windows 10): I have attached "bug-adaptRowHeight.ods" which is nothing more than a default blank ODS spreadsheet with a large block of numbers (1M file, 8000x40 cells). No formatting or anything. (If you think something is weird about this spreadsheet then just copy "numbers only" or "unformatted text" to your own new/blank spreadsheet instead and follow test.) This bug isn't noticable if you only have a small spreadsheet with a few cells and that is why this spreadsheet (or similar large one) is needed. (!) Your spreadsheet to test has to be large enough to be 'big' for your processor/cpu. This one is for my machine but it is consumer/mobile dual celeron and if you have a massive dev setup you might need to increase spreadsheet size in order to see the effect. OBSERVATION: with this spreadsheet open, use the arrow keys to move the cursor from cell to cell; notice there is no lag, no delay, and no flickering "adapt row height" message or progress bar appearing at the bottom. The cursor movement is normal and snappy. TEST STEP: Now select the entire spreadsheet and then click the font name dropdown arrow (as though you wanted to change the entire sheet's font). The list of available fonts will drop open and the current sheet font will be highlighted (Liberation Sans). Now...use the down arrow key to move the highlight selection to then next font. So (on my machine) "Liberation Sans" is highlighted and the font under it is "Liberation Sans Narrow". Thus, press down arrow to highlight it (but don't select). When you highlight "Liberation Sans Narrow" (or whatever font you have below the default; doesn't matter) LibreCalc will preview that font on the spreadsheet (but not actually change it yet; you would have to press enter to do that). Instead, press ESC to leave the font dropdown and *NOT* make any changes to the spreadsheet. The entire spreadsheet is still "Liberation Sans". (And UNDO will be blanked out.) BUG: again move the cursor around with arrow keys and notice there is now a delay and sluggishness! Each move from cell to cell has a pause and also you will see the bottom of screen flicker words "adapt row height" with a quick green progress bar. You didn't even change the spreadsheet, but just the act of previewing a different font has now permanently made the spreadsheet operate with a lag. It has somehow "damaged" the cells or sheet. NOTES: I have not found a way to reverse the program/cell 'damage' once the lag starts (after preview or font change). Since you didn't actually change the cells or font or formatting you can't just hit CTRL-Z to Undo. There is nothing to undo! You have to close the spreadsheet and reopen it to return to having no lag or no 'adapt row height' situation. If you have created the lagging/bug/"adapt..." situation (such as you went ahead and changed the page font), you can save that file, close LibreCalc, and then open the file. The lag/bug will go away (in other words the issue is NOT inherent in the actual file data stream.) If you then preview or change font the bug will come back. I have not found that program font settings (options) matter to this bug (anti-aliasing, use skia, show preview of fonts, etc). The default/starting font of your spreadsheet or the font you preview doesn't seem to matter. It is the act of previewing (or changing) from the starting/default font (on cells with contents) that breaks something. (I used numbers, but presume text or formula contents have same issue.) What matters is starting with a new/default/blank spreadsheet where the cells are untouched by any font actions. Cursor movement will be fine. Then paste in numbers (without formatting; "paste numbers" or "unformatted text") and THEN preview or change font at which point the bug appears. This bug seems to require cell contents and cells need to be 'touched' by the font preview (or change) in order to be 'damaged' and cause 'adapt row height' problem. Instead, if you take a default/new/blank spreadsheet, select the spreadsheet, and preview or change the sheet font BEFORE it has contents, and THEN paste a block of numbers ('paste numbers' or 'unformatted text') there will be no problem, no bug. The pasted numbers will (properly) be in the new font and the delay/sluggishness "adapt row height" bug/problem will NOT happen. (But if you THEN preview a different font it will.) Steps to Reproduce: above Actual Results: above Expected Results: above Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.5.2 (x86) / LibreOffice Community Build ID: 85f04e9f809797b8199d13c421bd8a2b025d52b5 CPU threads: 2; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Created attachment 174596 [details] large (only 1M) spreadsheet with block of numbers only
Trivial to "fix" a spreadsheet so it will not while bug 124098 gets some love as to errant handling of the use-optimal-row-height style. Open the Calc .ods archive in an exteranl Zip program; 7-zip works well on Windows. Select the 'content.xml' text file and edit. Find the stanza 'style:use-optimal-row-height="true"' and set its value to "false". Find any additional occurances (usualy just the one per sheet) and repeat the edit. Save the content.xml back into the .ods zip archive. Close the .ods archive. Reopen in Calc. Still an issue? => WFM Also, this "fix" can be done within the LibreOFfice UI, but it requires opening the sheets fully, slecting all, and applying a default row height--which is slow. Much quicker to do it external to LO directly in the ODF. Give either a try, you won't "break" your spreadsheet.
Repro from scratch, selecting A1:A1000000, filling series from 1 incrementing by 1, performing OBSERVATION, doing the TEST STEP from comment 0, and then navigating the sheet with arrows using Version: 7.2.1.1 (x64) / LibreOffice Community Build ID: 3cfc32d9754d2d239bd8ce2941029c12873010c1 CPU threads: 12; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: threaded Definitely a bug.
Already repro with Version: 4.2.0.4 Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71 but not in Version: 4.1.0.4 Build ID: 89ea49ddacd9aa532507cbf852f2bb22b1ace28, where the preview is already implemented! So a regression then.
1) Mike, thank you. Yes, easy reproduction can be just spreadsheet with a1:a1000000 containing number 1. (Increment isn't even necessary, just make spreadsheet with data). My upload spreadsheet is not necessary. 2) I believe you are saying this problem exists 4.2.0.4, but NOT 4.1.0.4? I can confirm this problem has been in many versions of Calc for months or years. I noticed it, but never took time to create official bug. 3)"V Stuart Foote" I do not understand (comment 2). You describe editing ODS file and then opening to see if still a problem. NOTE that I mentioned that the bug is not present in the file data stream. If 'lag'/"adapt row height" situation is created on a spreadsheet and then that spreadsheet is saved, then upon reopen the lag problem is gone (until font change is attempted again). The problem does not seem to be within ODS file data if that is your suggestion.
Remember this issue does NOT involve the changing of a spreadsheet. All that is necessary is to select sheet, highlight another font on dropdown (which causes Calc to preview the font on screen/sheet). But instead of changing font (do not press enter or click), just press ESC and make *no* spreadsheet change. UNDO will be grey; font stays same; but lag/adapt bug starts. The problem is in program not spreadsheet data changes.
LibreOffice>View>Preview fonts setting seems to imply "preview in the list" rather than on the sheet, and that works fine. Comments in Ask LO imply this should mean live preview since 2016. But in 7.2.2.2 I fail to see a separate setting for "live font preview" at all, and I don't see any live preview happening in small or large spreadsheets even with this setting marked. I have tried waiting for extended time after using arrow to highlight a different font. (The behavior seems to be that when clicking the drop arrow for the font selection field the font highlighted is not the current font but the last-selected (as in with Enter) font.)
Created attachment 176632 [details] Screen cast
This seems to have begun at the below commit. 06271499c829a52c702c2c6dc8f99c2ec9c46fd3 is the first bad commit commit 06271499c829a52c702c2c6dc8f99c2ec9c46fd3 Author: Matthew Francis <mjay.francis@gmail.com> Date: Sat Sep 5 20:42:38 2015 +0800 source-hash-bcc51fb2ebdf77a1cc089857775fd742085b45b6 commit bcc51fb2ebdf77a1cc089857775fd742085b45b6 Author: Noel Power <noel.power@suse.com> AuthorDate: Thu Aug 29 17:15:33 2013 +0100 Commit: Noel Power <noel.power@suse.com> CommitDate: Thu Aug 29 21:42:05 2013 +0100 add support for in-place style preview selecting a style in the styles dialog ( without double clicking ) will apply the style to the currently selected cell(s) You can with the keys navigate to other styles and they in turn will also be applied. Preview will end when you click back onto the document. *FIXME* - the styles dialog isn't really suitable for previewing, a new dialog ( possibly in the toolbar ) might be nicer ( see Excel ) *FIXME* - when there is a multiple selection the highlight colour (applied as a transparent overlay) is most annoying ( and is mixed with any background colour applied if part of a style ) see ( ScGridWindow::UpdateSelectionOverlay() ) However my puny attempts to make the selection use a transparent colour made all the borders of the selected cells dissappear. I guess maybe a box/border around each selected cell ( or group of cells ) would also work but I didn't try that Change-Id: I0950e79085ffb75f60ee961835665df0c230172f
*** Bug 161898 has been marked as a duplicate of this bug. ***
Version: 24.8.1.2 (X86_64) / LibreOffice Community Build ID: 87fa9aec1a63e70835390b81c40bb8993f1d4ff6 CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: threaded Still present in this version. The bug is created when we select several cells and apply a new font. The bug is disactivated when we don't select several cells and just go in the font combobox and valid. Is it really difficult to add this "disactivation" step after the "many cells" process? Thanks in advance for your analyze.
*** Bug 162546 has been marked as a duplicate of this bug. ***
Version: 24.8.2.1 (X86_64) / LibreOffice Community Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13 CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: threaded Still present in this version. I notice a difference between horizontal and vertical selection. The bug is NOT created when we select several cells HORIZONTALLY and apply a new font. The bug is created when we select several cells VERTICALLY and apply a new font. The bug is disactivated when we don't select several cells and just go in the font combobox and valid. It is now clear that the problem is created only when many lines are selected, it let activated a flag that repeats constantly a useless process each time we move the focus from cell to cell. We only need to disactivate this flag. Thanks in advance for your analyze.
I just stumbled across this and can confirm some of the behavior and offer some additional information. Our systems are all Linux/X with thin clients (remote displays). I am just now testing LO 24.8.3. Before that we have been using 7.5.7, and the problem doesn't exhibit there. And in 24.8.3, when I have a blank spreadsheet, or one with only a small number of cells, I see none of this. But if I have a large spreadsheet in 24.8.3 and then select all and change the font (with the pull-down selector), I notice multiple flickering drawing events on the bottom status area of LibreOffice every time the cursor is moved from one cell to another. I turned the network speed way down to try and read what it is saying, but it is still too fast. The text and icons there are being redrawn, maybe 10 times, and sometimes I see a progress bar as well for a tiny fraction of a second. It isn't causing any real performance issue for us in real-world use at full network speed, but it is a curiosity and certainly shows there is something inefficient/wrong. It is very curious that this ONLY ever happens when the font is changed using the pull-down menu. If I change them by right clicking and Format Cells, it doesn't do it. I can also confirm that it is when selecting lines of cells and not columns of cells that triggers the issue. If I save the file when it is in this broken/contaminated state, then close it and reopen it, the problem disappears. It is only if I try to change fonts in many cells, using the pulldown font menu, that it starts up again. I hope this is helpful.
Still reproducible in 24.8.4 on Windows. However, not reproducible in Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f3271cf5adfbe2e00d02417d85ff320763d7e9a5 CPU threads: 4; OS: Linux 6.12; UI render: default; VCL: kf5 (cairo+wayland) Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded Can someone test this with latest daily build on Windows?
Reproduced. Adjust row height worked. Version: 25.2.0.3 (X86_64) / LibreOffice Community Build ID: e1cf4a87eb02d755bce1a01209907ea5ddc8f069 CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL threaded