Description: Scrolling complex document at zoomlevel 50% appears to be slower Steps to Reproduce: 1. Open attachment 133938 [details] (bug) 2. Set zoomlevel to 50% 3. Scroll to bottom and up using the vertical scroll bar Actual Results: It's smooth pretty smooth in 5.2.4.2 but sluggish with 6.0.0.0 Expected Results: Similar to 5.2.4.2 Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 6.0.0.0.alpha0+ Build ID: cbf371e07fd5dea1ea08a1f299360d1273961ebd CPU threads: 4; OS: Windows 6.19; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-06-14_23:13:57 Locale: nl-NL (nl_NL); Calc: CL and in Versie: 5.3.3.1 Build ID: 46360c72c4823cefeaa85af537fba22bd568da7e CPU Threads: 4; Versie besturingssysteem:Windows 6.2; UI Render: standaard; Layout-Engine: nieuw; Locale: nl-NL (nl_NL); Calc: single but not in Versie: 5.2.4.2 Build ID: 3d5603e1122f0f102b62521720ab13a38a4e0eb0 CPU Threads: 4; Versie besturingssysteem:Windows 6.2; UI Render: standaard; Locale: nl-NL (nl_NL); Calc: CL User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
I reproduce this behavior with the attached file. I have the same problem with my Calc files a bit complex, scrolling is slow and sometimes jerky. This problem has occurred with version 5.3 Harware acceleration, anti-aliasing and OpenGL are all unchecked Tested with: Version: 5.3.3.2 Build ID: 3d9a8b4b4e538a85e0782bd6c2d430bafe583448 Threads CPU : 4; Version de l'OS :Windows 6.0; UI Render : par défaut; Moteur de mise en page : nouveau; Locale : fr-FR (fr_FR); Calc: group Compared to: Version: 5.2.7.2 Build ID: 2b7f1e640c46ceb28adf43ee075a6e8b8439ed10 Threads CPU : 4; Version de l'OS :Windows 6.0; UI Render : par défaut; Locale : fr-FR (fr_FR); Calc: group
For the moment Windows only problem. I do not have LO 5.2 on my Ubuntu 16-04 but I do not see real problem when scrolling through this file with LO 5.3.5.0+ or LO 5.4.0.1.0+ (x86-64). Best regards. JBF
Another example (Writer) 1. Open attachment 63259 [details] (bug 47636) 2. Set to multi-page view with 3 pages on the screen 3. Scroll up and down with the page up/down Immense slow in: Versie: 5.4.0.1 Build ID: 962a9c4e2f56d1dbdd354b1becda28edd471f4f2 CPU-threads: 4; Besturingssysteem:Windows 6.2; UI-render: standaard; Locale: nl-NL (nl_NL); Calc: CL jerky scrolling with Version: 5.3.0.3 Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1 CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; Locale: nl-NL (nl_NL); Calc: CL fine with: Version: 5.3.0.0.alpha1 Build ID: f4ca1573fcf445164c068c1046ab5d084e1b005f CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Locale: nl-NL (nl_NL); Calc: CL
Effectively caused by bug 108703 and 109174
*** Bug 108934 has been marked as a duplicate of this bug. ***
Slow in Versie: 5.3.2.2 Build ID: 6cd4f1ef626f15116896b1d8e1398b56da0d0ee1 CPU Threads: 4; Versie besturingssysteem:Windows 6.2; UI Render: standaard; Layout-Engine: nieuw; Locale: nl-NL (nl_NL); Calc: CL fast in Versie: 5.3.1.2 Build ID: e80a0e0fd1875e1696614d24c32df0f95f03deb2 CPU Threads: 4; Versie besturingssysteem:Windows 6.2; UI Render: standaard; Layout-Engine: nieuw; Locale: nl-NL (nl_NL); Calc: CL
*** Bug 112570 has been marked as a duplicate of this bug. ***
(In reply to Jean-Baptiste Faure from comment #2) > For the moment Windows only problem. > I do not have LO 5.2 on my Ubuntu 16-04 but I do not see real problem when > scrolling through this file with LO 5.3.5.0+ or LO 5.4.0.1.0+ (x86-64). I can confirm this bug for Mac OS 10.12.6 as well. Scrolling the provided file is jerky with LO 5.4.0.3 – but ok with LO 5.1.6.2 and LO 5.2.3.5.
Closing as WFM. No issue 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
I would suggest to not close this issue until it's fixed in 5.4 and 6.0. This issue is still reproducible in 5.4.2.2. LibO needs about 500 MB of RAM and is still freezing occasionally. Version: 5.4.2.2 (x64) Build-ID: 22b09f6418e8c2d508a9eaf86b2399209b0990f4 CPU-Threads: 8; Betriebssystem:Windows 6.19; UI-Render: Standard; Gebietsschema: de-AT (de_DE); Calc: group
(In reply to Thomas Lendo from comment #10) > I would suggest to not close this issue until it's fixed in 5.4 and 6.0. I agree, it's too early to close this bug. Very pleased that it is fixed on: Version: 5.3.7.0.0+ Build ID: 8d9b236dcb3fd0f7028e4d19ede04589cf85d760 CPU Threads: 4; OS Version: Windows 6.0; UI Render: default; Layout Engine: new; TinderBox: Win-x86@62-TDF, Branch:libreoffice-5-3, Time: 2017-10-04_10:19:33 Locale: fr-FR (fr_FR); Calc: group But still present with: Version: 5.4.2.2 Build ID: 22b09f6418e8c2d508a9eaf86b2399209b0990f4 Threads CPU : 4; OS : Windows 6.0; UI Render : par défaut; Locale : fr-FR (fr_FR); Calc: group
Fix will be available in 5.4.3. https://bugs.documentfoundation.org/show_bug.cgi?id=112486#c12
Smooth scrolling restored to master. Version: 6.0.0.0.alpha0+ (x64) Build ID: b087e451527f2e497ccab83b63b4f10099bfb8b8 CPU threads: 8; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2017-10-04_00:55:56 Locale: en-US (en_US); Calc: CL Fixed in master/6.0, 5.4 and 5.3 by Xisco and Khaled for work on bug 112486 -- Do not force GDI in no OpenGL With that correction, scrolling is again snappy. Additional work on DirectWrite font handling may again affect this, but for now fixed. =-ref-= https://cgit.freedesktop.org/libreoffice/core/commit/?id=01f674a95ddec76dc4c8ecfccdca1773657e47cb https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-5-4&id=2ed67ed55ad929eb9363a5c4e3c55b3ee857d984 https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-5-3&id=5440837e02dee8bc884e02be697bfd4def621d26
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.
Currently there's no way to enable the DirectWrite from the UI, thus closing as RESOLVED WORKSFORME