Description: I have previously reported (couple of years ago?) this and was given a workaround of ctrl-M. I could then apply my formatting and it wpould be OK for a while. Now as soon as I start formatting again the sluggish behaviour is immediate. Background: I proofread/verify files which come to me in csv format. I load them into ods format and then format them by changing font to courier new, resize columns, freeze the first two rows. Then as I check blocks of rows I change font colour to green to bookmark my progress. The files can contain 3500 to 6500 rows. Usually the sluggishness sets in around 1000 rows in, obvious because scrolling is not smooth and a Save takes a minute or more to complete. Auto save is ON which might be relavent to the scrolling? But it is now happening almost as soon as I start formatting away from the default font and layout. Behaviour is better if I don't change font, but I find it easier to use a sans-serif one. I am using vn 24.2.3.2, installed in the last week, but the behaviour has been there across previous versions too (I was previously using vn 7.x.x) on Windows 11. Steps to Reproduce: 1. open .csv in .ods format 2. change default font to courier new across all rows (click top left to select all), freeze top 2 rows, resize columns to better fit the data and show max cols on a 15" laptop screen 3. scroll through data, select last in a group of rows change font colour to green. 4. auto save is ON, but manually save approx every 25 rows. Actual Results: Saving and scrolling is intially quick and smooth but quickly deteriorates. Expected Results: Saving and scrolling should be fast and not lumpy. Reproducible: Always User Profile Reset: Yes Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: SpreadsheetDocument [Information guessed from browser] OS: Windows (11) OS is 64bit: yes Version: 24.2.3.2 (X86_64) / LibreOffice Community Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba CPU threads: 8; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-US Calc: threaded
Created attachment 194723 [details] example of sluggish ods file
I think you are setting the font incorrectly, applying a direct format that is not the default. If you want to set the default font, you need to edit 'Default style' and change the font there. This style is the root of all styles in the spreadsheet. Also remember that you can modify the templates, to set default parameters when you create a new file. https://help.libreoffice.org/latest/en-US/text/shared/guide/template_manager.html?&DbPAR=WRITER&System=WIN
Thank you for this. I have created a template based on the formatting I need, and saved it as the Default template. If I create a new spreadsheet the formatting is there which is great. However, when I create a new spreadsheet by double-clicking on a .csv file, or using File-Open, the template is not applied to the data in that file. Instead the font is LiberationSans so I'm no further forward. I have tried creating an empty spreadsheet then copying the data in but it retains the original font. I've searched through Help but can't find anything that relates to applying a template as a file is imported in this way. There must be a way to do what I need to. Can you advise please? Regards, Brian
Have you set up the template as default template? Menu/File/Templates/Manage templates Right-click on it and set as Default.
Yes it is the default template. Doesn't seem to apply when opening a .csv
Have you tried instead open the CSV directly, creating a new spreadsheet and use Menu/sheets/Insert sheet.. or External link. *** This bug has been marked as a duplicate of bug 131274 ***
Have tried both of these but with same result. Default template is ignored.
*** This bug has been marked as a duplicate of bug 86336 ***
I have set it to a duplicate of bug 86336, just because previously it was marked as a duplicate of bug 131274. However, I don't see why this one would be a duplicate of either. The problem is a *sluggish ODS*. How could one see it as a duplicate of a *CSV* issue is beyond me.
(In reply to Brian P from comment #3) > when I create a new spreadsheet by double-clicking on a .csv file, > or using File-Open, the template is not applied to the data in that file. When you double-click a CSV file, you are not "creating a new spreadsheet", but you are opening an existing file. If then you save it with a new name (and a new type), you are just creating a copy of the original document. In no stage did you create a new spreadsheet in this sequence. And as always, when you open any existing document, no external documents (like templates) are (nor should be) used to decide how this opened document will look like. It is possible to apply a template to an existing document, using Template Changer extension [1]. However, I doubt that it would help, because changing the template would only update styles, not replace direct formatting. Anyway, the topic of the formatting applied when opening a CSV is unrelated to the issue of the ODS being sluggish (even if the ODS was initially created from a CSV). The original idea of comment 2 is wrong: no matter what the formatting is, it is not an excuse for Calc to perform slowly because of that. This is a clear perf issue if it is reproducible - the file seems quire responsive to me, using Version: 24.2.5.1 (X86_64) / LibreOffice Community Build ID: 2ccb78ad6bdfe3f3356a7a7f294ec388775c5816 CPU threads: 24; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL threaded. [1] https://extensions.libreoffice.org/en/extensions/show/27416
Created attachment 195976 [details] Perf flamegraph of changing text colour of a row and scrolling down I observe sluggishness when scrolling after changing the text colour of a row. Not really otherwise. The biggest chunk of time seems to be spent in ScPatternAttr::IsVisibleEqual Saving is also quite slow, 30+ secs on Windows and 20+ secs on Linux. Arch Linux 64-bit Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e1a4cdb3564c38ac1b75cc076c6762369e79137c CPU threads: 8; OS: Linux 6.10; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded Built on 23 August 2024
(In reply to Buovjaga from comment #11) > Created attachment 195976 [details] > Perf flamegraph of changing text colour of a row and scrolling down > > I observe sluggishness when scrolling after changing the text colour of a > row. Not really otherwise. The biggest chunk of time seems to be spent in > ScPatternAttr::IsVisibleEqual Oh, the slowness is indeed only after saving one time.
Bibisected the current state with linux-64-24.2 to eb13c889c760cfe153d5b41188e218bdda797d52 Speed up scrolling through large document with lots of patterns Optimise comparison in ScPatternAttr::IsVisibleEqual Let's ask Noel what he thinks. When bibisecting, I always reset to the original attachment 194723 [details] when opening as using a document saved with an older version seemed to have an effect. What I did: 1. Changed the colour of one row 2. Saved (did not reload) 3. Changed the colour of another row 4. Scrolled down
Sorry, I can't reproduce this, seems fine to me
(In reply to Noel Grandin from comment #14) > Sorry, I can't reproduce this, seems fine to me Doing the steps from comment 13, there is a lag of about 5 secs before it reacts to scrolling. After reverting your commit, there is still a lag, but only about 1 sec.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/944fbe89fd48fa7814c0b33ef22910e8221da9de tdf#161562 Sluggish scrolling after saving and changing text color It will be available in 25.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.
(In reply to Buovjaga from comment #15) > (In reply to Noel Grandin from comment #14) > > Sorry, I can't reproduce this, seems fine to me > > Doing the steps from comment 13, there is a lag of about 5 secs before it > reacts to scrolling. After reverting your commit, there is still a lag, but > only about 1 sec. A detail: the lag was with scrollwheel. With scrollbar, there was movement immediately, but the view was unresponsive after that.
Brian: can you confirm with Win-x86_64@tb77-TDF from https://dev-builds.libreoffice.org/daily/master/current.html that the scrolling issue is gone?
No.The issue is not just scrolling but laggardly saving and moving around the spreadsheet after a number of direct formatting changes have been made.I'm currently working on a ss of ~3500 rows. I started by changing the font from Liberation to Courier across the ss. Fixed the top 2 rows as these are headers. As I work through the ss I'm correcting text and changing the font colour of some rows so I can keep track of progress. The ss is often being worked on for 1+ hour at a time. Auto Save is On. I manually save after working on 20-25 rows. Initially everything is smooth. Today I have reached row 218 in my checking and the Save function is now palpably slow. If I take no action the response in the ss will get slower and slower.The action I will eventually take (learnt from trial & error) is to clear direct formatting across the ss. Save. Change font of unchecked rows back to Courier. Save. The Save function is usually now instantaneous. After working on a number of rows the laggardly response will come back. The number of rows doesn't seem to be relevant - it could be a few 100s or 1000. I suspect it's the number and/or frequency of changes and/or the length of time the ss is open? I am going to revert from this dev version back to the current release for Winx64. Brian On Mon, 23 Sept 2024 at 19:05, <bugzilla-daemon@bugs.documentfoundation.org> wrote: Comment # 18 on bug 161562 from Buovjaga Brian: can you confirm with Win-x86_64@tb77-TDF fromhttps://dev-builds.libreoffice.org/daily/master/current.html that the scrollingissue is gone? You are receiving this mail because: You reported the bug.
(In reply to Brian P from comment #19) > No.The issue is not just scrolling but laggardly saving and moving around > the spreadsheet after a number of direct formatting changes have been > made.I'm currently working on a ss of ~3500 rows. I started by changing the > font from Liberation to Courier across the ss. Fixed the top 2 rows as these > are headers. As I work through the ss I'm correcting text and changing the > font colour of some rows so I can keep track of progress. The ss is often > being worked on for 1+ hour at a time. Auto Save is On. I manually save > after working on 20-25 rows. > Initially everything is smooth. Today I have reached row 218 in my checking > and the Save function is now palpably slow. If I take no action the response > in the ss will get slower and slower.The action I will eventually take > (learnt from trial & error) is to clear direct formatting across the ss. > Save. Change font of unchecked rows back to Courier. Save. The Save function > is usually now instantaneous. After working on a number of rows the > laggardly response will come back. The number of rows doesn't seem to be > relevant - it could be a few 100s or 1000. I suspect it's the number and/or > frequency of changes and/or the length of time the ss is open? > I am going to revert from this dev version back to the current release for > Winx64. There is no need to "revert" as the dev build is a separate install with its own user profile. I am mainly interested in the scrolling issue described in my comment 11. Do you observe it anymore using the scrollwheel in the dev build?
Nice of someone to explain that. I'll let you know when I have tested the dev vn then.
Sorry but yes scrolling with the mouse wheel is still lumpy, but as I said in my prior comments this is one of a number of symptoms. I have now progressed to row 834. A save now takes 20s to complete, copying a cell (ctrl-c) takes 4s, scrolling is sometimes OK sometimes lumpy, selecting a cell or a row is sometimes OK sometimes takes a second or two.
Created attachment 196841 [details] Screen recording of no lag when scrolling This recording is taken with a build that includes Noel's reverting commit 944fbe89fd48fa7814c0b33ef22910e8221da9de
Created attachment 196842 [details] Screen recording of lag when scrolling Recording taken after git revert --no-commit 944fbe89fd48fa7814c0b33ef22910e8221da9de make sc The lag in scrolling is clear. Notably, the saving also takes a long time.