LO version 5.4.1.2 is very reluctant (see below) compared to LO 5.3.1.2 which itself is slow, in comparison to Apache Open Office 4.1.2 used on the same Dell Optiplex 755 PC. I can compare it to Apache Oo: Apache Open Office version 4.1.2 with Java 8 update 121 is very smooth and fast. In Windows 10 in Performance Options > Visual effects; Unchecking animations is no help. In LibreOffice > Tools > Options >Memory; Increasing allocated memory for Libra Office has no effect. When selecting and dragging cells the mouse will often drop the cells or move the cells. It isn't a mouse or mouse driver issue: this does not occur with Apache Open Office. It makes the task risky. Selecting cells across dozens of columns of cells, each with formulae, slows the selection process enormously. It looks like a memory or re-calculation issue not present in Apache Oo. Thank you.
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 137051 [details] Sample spreadsheet that can demonstrate the unresponsiveness Bug 113158 File attached: A sample document showing slow response: scrolling, selecting cells and dragging across spreadsheet, and traversing with left/right arrows across spreadsheet. Sporadic performance from moderately affected to badly impaired. Apache Open Office is lightning fast and appears not afflicted. It's possibly a memory/CPU resource issue - it's worse when an anti-virus scan is running. LibreOffice can be slow and unresponsive in comparison to Apache Open Office. I have a feeling it depends on the background processes that are running. LibreOffice may be very hungry. I am wondering if Apache OpenOffice does the cell selecting and any formula recalculating sequentially as serial tasks and LibreOffice does them combined. The Dell 755 (Windows 10 Pro 64-bit) doesn't prompt that there is a low virtual memory and Process Lasso (A CPU optimizer that improves mouse responsiveness ) or Task Manager doesn't show a huge CPU or RAM problem. Apache Open Office runs rings around LibreOffice in this task. There is criticism appearing on the Internet. The sample spreadsheet is small; if a "Find and Replace" dialogue box is placed on the spreadsheet it increases the unresponsiveness of LibreOffice as the bordered cell is traversed across and below it. Apache OpenOffice developers designed a super product and Java frustrated it. I use an old version for the letter wizards. It's tough on LibreOffice. Puzzling!
Most or all of the described issue are likely caused by bug 112486. Targeted versions are: 5.3.7 and 5.4.3 and 6.0.0. You could try 5.3.7 testing or wait for the final release. http://www.libreoffice.org/download/download/?type=win-x86&version=5.3.7&lang=en-US https://wiki.documentfoundation.org/ReleasePlan/5.3
Reply, Thank you (Telesto) for having a look into my bug 113158. I had a look at Bug Report 112486, that you mentioned. I have just had a look at LibreOffice Version 5.3.7.1 (V 5.3.7 rc 1) and i have just run it. It is just as bad at sticking and stuttering as LO 5.3.4.2 (Calc) and LO 5.4.1.2 (Calc). Same problem: it gets much worse if an anti-virus scan is run in the background; it will start to drop selected cells, freeze or move them. With the same spreadsheet Exit and immediately "Open with" Apache Open Office and there is perfection: no issues. Apache OpenOffice is blisteringly fast. I moved from Apache Oo when the Java 8 Update 131 caused issues and the letter wizards died. Even then, I found LibreOffice was slow when scrolling. I have a horrid feeling that it's a congenital deformity in the LO branch; aetiology presently unknown. Good luck with the investigation. I will keep an eye on the thing and try the updates as they arrive. I'm a microbiologist so not a critical component at Bugzilla BUT: thanks all the same... From Simon Noble
Thanks for the quick response :-). And I found a way to reproduce this. It's OpenGL related. Disabling OpenGL should work: go to Tools ▸ Options ▸ LibreOffice ▸ View to disable OpenGL. Repro with: Version: 6.0.0.0.alpha0+ Build ID: c5a93cad149618bbd43632f1660a558c34bdbf7e CPU threads: 4; OS: Windows 6.3; UI render: GL; TinderBox: Win-x86@42, Branch:master, Time: 2017-10-07_01:04:25 Locale: en-US (nl_NL); Calc: CL
Created attachment 137061 [details] Bibisect log Bisected to the following commit: author Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk> 2017-07-21 07:15:27 (GMT) committer Michael Stahl <mstahl@redhat.com> 2017-07-21 10:44:36 (GMT) commit e197b4a88c421201e157552f94e7eaaa00a76269 (patch) tree 0d5afd4f6b101195b26d24c87cb4c32a3d0266af parent 4a169551433a0897ca9b1baccbfce134059aef05 (diff) tdf#107166 improve AA mode selection, retry, more checks Major problem when setting the render mode and the text antialias mode is that when you set the render mode to something that isn't compatible with the text antialias mode, then every next call will cause an error (invalid parameters). So we need to be sure that we never set incompatible modes. Additionally we just need to set it one time when we create the surface and not every time we draw. If we get the D2DERR_RECREATE_TARGET we can create a new render target and retry the whole call. Somethimes this is not possible so we try 3 times and the give up. We need to add more checks where we exit early or not continue with some calls as any additional calls could taint the draw state and some things wouldn't be drawn. For example if we calculate the sizes of 0 glyphs we shouldn't continue with binding the hDC with an "empty" rectangle. This will fail and cause some text that is called afterwards to not draw.
Just to be sure, could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ? You can install it alongside the standard version. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
*** This bug has been marked as a duplicate of bug 107355 ***
(In reply to Xisco Faulí from comment #7) > Just to be sure, could you please try to reproduce it with a master build > from http://dev-builds.libreoffice.org/daily/master/ ? > You can install it alongside the standard version. > I have set the bug's status to 'NEEDINFO'. Please change it back to > 'UNCONFIRMED' if the bug is still present in the master build Also a repro with: Version: 6.0.0.0.alpha0+ Build ID: a4a182e24d2e3e954831a0a7c70a7299f28950cb CPU threads: 4; OS: Windows 6.3; UI render: GL; TinderBox: Win-x86@42, Branch:master, Time: 2017-10-18_04:47:29 Locale: en-US (nl_NL); Calc: CL
Adding Cc: to Tomaž Vajngerl
Re: Telesto 2017-10-17 Comment 4 My LO Calc spreadsheets now all running OK using Version 5.3.7 rc1. It needed a Restart I guess. Looks and handles like Apache Open Office. Fast smooth and looks OK. I can not invoke any unresponsiveness however hard I try to load the computer up with scans running in the background. Problem resolved I guess.
(In reply to Telesto from comment #5) > Thanks for the quick response :-). And I found a way to reproduce this. It's > OpenGL related. > > Disabling OpenGL should work: go to Tools ▸ Options ▸ LibreOffice ▸ View to > disable OpenGL. > > Repro with: > Version: 6.0.0.0.alpha0+ > Build ID: c5a93cad149618bbd43632f1660a558c34bdbf7e > CPU threads: 4; OS: Windows 6.3; UI render: GL; > TinderBox: Win-x86@42, Branch:master, Time: 2017-10-07_01:04:25 > Locale: en-US (nl_NL); Calc: CL Re: Telesto 2017-10-17 Comment 4 My LO Calc spreadsheets now all running OK using Version 5.3.7 rc1. It needed a Restart I guess. Looks and handles like Apache Open Office. Fast smooth and looks OK. I can not invoke any unresponsiveness however hard I try to load the computer up with scans running in the background. Problem resolved I guess.
(In reply to Telesto from comment #5) > Thanks for the quick response :-). And I found a way to reproduce this. It's > OpenGL related. > > Disabling OpenGL should work: go to Tools ▸ Options ▸ LibreOffice ▸ View to > disable OpenGL. > > Repro with: > Version: 6.0.0.0.alpha0+ > Build ID: c5a93cad149618bbd43632f1660a558c34bdbf7e > CPU threads: 4; OS: Windows 6.3; UI render: GL; > TinderBox: Win-x86@42, Branch:master, Time: 2017-10-07_01:04:25 > Locale: en-US (nl_NL); Calc: CL From Simon Noble Just in case it matters; all going fine with bug resolved in 5.3.7.1 rc1. I also worked out how to install and run LibreOfficeDev 6.0.0.0alpha0 also known as: libo-master64~2017-10-8_11.40.11_LibreOfficeDev_6.0.0.0.alpha0_Winx64.msi It ran smoothly, no issues and the font looks OK on the screen. You are geniuses. I could not enable OpenGL to try to reproduce the bug. Good! Long standing bug fixed. Kind regards from Simon
Closing as WFM, based on comment 13
(In reply to Telesto from comment #14) > Closing as WFM, based on comment 13 Thank you Telesto: for the assistance. I enjoyed the brief meeting. All quiet and running smoothly; LO and Bugzilla both looking good. Open Source all OK. On to the next puzzle then! From Simon.