Description: I have a spreadsheet that has quite a lot of data, to fill full screen width and several pages in height. Some minor formatting is used, as bold text and background colors for one column. No calculations are used at all, it's only simple formatted data. When scrolling with scrollbar there is noticeable lag before redraw. Scrolling is not smooth. There are no problems with scrolling when there's no data in sheet. Also, after restoring minimized window it takes a second or two to draw main spreadsheet data, system UI (menus, toolbars) appear instantly. Hardware acceleration and OpenCL is not used. Steps to Reproduce: 1. Open worksheet with a lot of data to fill the screen. 2. Try scrolling sheet using scrollbar. 3. Try minimizing and maximizing Calc window. Actual Results: Laggy scrolling and slow redraw. Expected Results: Smooth scroll and instant redraw. Reproducible: Always User Profile Reset: Yes Additional Info: Automatic spellchecking is disabled, same issues occur when running in safe mode. Problems started a few versions ago, probably since 5.3 release. User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0
Hello, Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Created attachment 132756 [details] sample document I've attached first sample document I could find on the net, it still has same issues as my spreadsheet.
it seems like your profile is corrupted. could you please reset your Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and re-test? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present
I see same issues when running in safe mode. Just tested older version 5.2.6, from portable installation, and it performs much better.
Confirming with: Version: 5.4.0.0.alpha0+ Build ID: 4354f0e9ef4a5538729a2a6f2d1745e247f6c5cd CPU threads: 4; OS: Windows 6.19; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-04-21_06:05:57 Locale: nl-NL (nl_NL); Calc: CL and - related to comment 4 - not with: Version: 5.2.5.0.0+ Build ID: a4d4fbeb623013f6377b30711ceedb38ea4b49f8 CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; TinderBox: Win-x86@62-merge-TDF, Branch:libreoffice-5-2, Time: 2016-12-24_14:43:55 Locale: nl-NL (nl_NL); Calc: CL
Please test disabling Menu/Tools/Automatic spell checking.
Created attachment 134619 [details] ODS test file for slow display speed Hi, the slow Display speed I've detected on bigger Tables. (s. example) The easy Test is to press 'Strg + End' ('Strg + Ende' on German Keyboard) and wait after the position is on display press 'Strg + Home' ('Strg + Pos1' on German Keyboard). Since LibreOffice 5.3 the display speed is much slower than on LibreOffice 5.2 and before. The attached example document has one table of the size 100 columns and 2000 rows. Regards, AnFr
Created attachment 134629 [details] simple example - low size file Hi, I've added a low size file to that shows the same behavior than the previous one. With Kind Regards, AnFr
Visible also in: Version: 6.0.0.0.alpha0+ Build ID: 2f2eba56d1f8ec5cdcadb4852e8856858477c008 CPU threads: 4; OS: Windows 6.19; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-07-09_10:12:58 Locale: es-ES (es_ES); Calc: group
Info: The slow redraw 'speed' is Tool setting independent. "Automatic Spell Checking" and "AutoInput" active or inactive results into the same behavior.
In portable versions: BUG not confirmed: Version: 5.3.1.2 Build-ID: e80a0e0fd1875e1696614d24c32df0f95f03deb2 CPU-Threads: 4; BS-Version: Windows 6.1; UI-Render: Standard; Layout-Engine: neu; Gebietsschema: de-DE (de_DE); Calc: group First time confirmed in: Version: 5.3.2.2 Build-ID: 6cd4f1ef626f15116896b1d8e1398b56da0d0ee1 CPU-Threads: 4; BS-Version: Windows 6.1; UI-Render: Standard; Layout-Engine: neu; Gebietsschema: de-DE (de_DE); Calc: group Regards, AnFR
This bug appeared at the same time this "feature" where the whole user interface gets anti-aliased and no option will change that. All redraw is super slow compared to non-anti-aliased version (5.3.1.2 ? and confirmed with portable 5.2.7.2), especially so in big files. Enabling Hardware acceleration and OpenGL seem to alleviate a bit of this slowness but still very slow. When I press a menu option I can see the grey rectangle before the text appears on top, this didn't happen in previous versions. In some sheets I can see each cell's format being changed one by one. Disabling auto-correct etc doesn't help. I can confirm this problem in 5.3.3.2 x64 Windows 8.1, the previously installed version didn't suffer from this but can't remember which version it was (is there a cumulative LO install log?) UPDATE: Just installed 5.3.4.2 x64 and it looks almost as fast as 5.2.7.2. Still some anti-aliasing going on (perhaps an OpenGL option in the driver?) and OpenGL is in use although tickbox is deselected on restart as reported in https://bugs.documentfoundation.org/show_bug.cgi?id=108533
Hi, I got this Big Data effect with slow down and annoying speedloss also. (35000 rows and 64 Columns mixed data, text and numbers, 3 to 5 sheets in one ODS file) I filled up the sheets with simple formatted Data, no formula, only to sort the columns for creating clean CSV files. This is a great function of libre Office calc also the field formatting I love. 1. First I killed all automatic spellchecking, this helped ... I was thinking for a moment ... very good. Then I go ahead with editing and like joshas speek, the scolling gots crazy. 2. I pressed the down key to step line by line ... no effect or extremly slow. 3. Then I checked the mouse on the right slider, and this was a big mistake. Then the table was fully grey no fillings and the slider on right side constantly jumps slowly, I guess page by page, unvisible up or down depends on the direction I clicked before. After 5 Minutes I killed the task. Good luck no data loss. I repeated, after restart, my checks, but now I give up. The saving of the sheets shows in the same way big loss of speed. Doing the same work in MS Excel, I can run additional functions, macros and VBA scripts without any bad effect like this. I hope you will find the solution .... Here the details to the software: Version: 5.3.3.2 (x64) Build ID: 3d9a8b4b4e538a85e0782bd6c2d430bafe583448 CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; Locale: en-US (en_US); Calc: group
Hi, because of the significant performance loss this BUG needs a much higher classification. For Info: In our company it is classified as show stopper, so no update to 5.3.x or higher will be done till BUG is fixed. Regards, AnFr
No repro with: Version: 5.3.7.0.0+ Build ID: 8580472270972733cda7fa6ecf23db73359d30bb CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; TinderBox: Win-x86@62-TDF, Branch:libreoffice-5-3, Time: 2017-10-02_13:08:01 Locale: nl-NL (nl_NL); Calc: CL Repro with: Version: 6.0.0.0.alpha0+ Build ID: f50bf3c5225b49b3c6f77f882e35305e5dc5ccd3 CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-10-03_03:54:36 Locale: nl-NL (nl_NL); Calc: CL =-ref-= http://dev-builds.libreoffice.org/daily/libreoffice-5-3/
Didn't test myself. But I guess it's solved with Bug 112486 that was in 5.3.7 and later in 6.0: https://cgit.freedesktop.org/libreoffice/core/commit/?id=01f674a95ddec76dc4c8ecfccdca1773657e47cb. SO I'll close as WFM. Feel free to reopen if repro again with 5.3.7 or 6.0 as of 2017-10-04.
This is a problem in DirectWrite, thus it's not fixed. My commit only changes the behaviour to use GDI instead, as it was before. The plan is to move to DirectWrite at some point. Keeping it open.
*** Bug 113158 has been marked as a duplicate of this bug. ***
Currently there's no way to enable the DirectWrite from the UI, thus closing as RESOLVED WORKSFORME