Description: Hi, when I hide all columns and only use a few columns to have a cleaner view, the scrolling becomes very slow. Steps to Reproduce: 1. Open the Calc file. 2. Hide all columns and only keep some of them visible. 3. Do scrolling Actual Results: The Scroll becomes slow. Expected Results: The scroll should be fast. In Microsoft Excel works. Reproducible: Always User Profile Reset: Yes Additional Info: None
Have you enabled? Menu/Tools/Options/LibreOffice calc/Default/Enable very large spreadsheets. Please can you paste the information in Menu/Help/About LibreOffice, there is an icon to copy.
I haven't the check "Enable very large spreadsheets" option in version 7.4.7.2. I can't enable it. I don't understand where you want me to paste the information. Thanks you
I guess that the only way to reproduce this is with a file. Additionally, version 7.4.7.2 will not receive additional Community updates. (In reply to Gabro from comment #2) > I don't understand where you want me to paste the information. Open LO > Menu Help > About; there is an icon to copy the info to the clipboard. Come back to the report and paste the info in a new comment. I would first suggest testing with a newer version (or with a Development version installed in parallel).
I added additional information to reproduce the case. 1. First, open a new file in Calc and select, for example, the "G" column. 2. Then, press Ctrl+Shift and the right arrow key to select all columns to the right. 3. Right-click on the header of the "G" column and choose "Hide Columns". All of them will be hidden. At this moment, you can scroll and observe that it works more slowly than before. Version: 7.4.7.2 (x64) / LibreOffice Community Build ID: 723314e595e8007d3cf785c16538505a1c878ca5 CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: es-ES Calc: threaded Thanks you
The STR in comment 4 are easy-enough to follow. With _different_ scrolling rates in each version (i.e. other factors could be in place for each version), it could be reproduced since LO 3.3 and up to current Dev 24.2. OTOH, with the same STR, we cannot really be sure that the performance reduction is originated by _hiding_ (so many) columns, or by applying some/any attribute to such a big area. IOW, is _hiding_ the problem? Or is it the "huge" range of "active" cells? Further investigations would be needed. There are probably similar reports open already; let's set to NEW for now.
Created attachment 188514 [details] Example
Smooth with Version: 7.0.7.0.0+ (x64) Build ID: 626ea4e62a3e5005fe9825923a1c0c5bdb61cc08 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Bibisected win64-7.4. Note that the commit was introduced to fix Bug 152094. Regression introduced via: https://git.libreoffice.org/core/+/344d90b20bdf95e9888f916672bbe51a5d700d02 commit 344d90b20bdf95e9888f916672bbe51a5d700d02 [log] author Caolán McNamara <caolanm@redhat.com> Wed Nov 23 17:29:56 2022 +0000 committer Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Wed Dec 14 11:09:08 2022 +0000 tree 9d9d519518044a90c67bbd1aaf42a4a2f5a662d1 parent 94e3ddb97b1eb0761c09ce56e053f85cd215cbf4 [diff]
Still sluggish. Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9bc5b89c149497a83117edfadc3fb0b96d2f9899 CPU threads: 2; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Lets revert, text placement has moved on since the original thing anyway so lets restore the original optimization
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a6dc33e5b4af22ef150ca328ad67132e85ec3dbe Resolves: tdf#156297 restore copy area optimization It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/3fa6bed062d7fd840eb75c18390e0384695af827 Resolves: tdf#156297 restore copy area optimization It will be available in 25.8.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 153399 has been marked as a duplicate of this bug. ***
*** Bug 155286 has been marked as a duplicate of this bug. ***