Description: When I move up or down through a Calc spreadsheet version 5.3.4.2, there is a delay of app. one second, when I press Page UP or Page Down. The same delay appears when I switch between tabs. This problem didn't exist in the previous version (5.2.7.2) and after I uninstalled version 5.3.4.2 and reinstalled 5.2.7.2 the problem has disappeared. So it only appeared in the new version of Calc. The problem does not occur in spreadsheets created in version 5.3.4.2 itself but "only" in all the speadsheets created in earlier version of Calc. Steps to Reproduce: 1. Press Page Up, Page Down or switch between tabs 2. 3. Actual Results: The buttons does what they are supposed to, but with a delay of app. one second per click, which makes Calc useless. Expected Results: The buttons does what they are supposed to, but with a delay of app. one second per click, which makes Calc useless. Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36
Thank you for reporting the bug. To be certain the reported issue is not related to corruption in the user profile, 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
@brunojapp: did you tried to reset profile? If it doesnt help, please attach test file (you wrote: The problem does not occur in spreadsheets created in version 5.3.4.2 itself but "only" in all the speadsheets created in earlier version of Calc.) Thanks
Created attachment 134966 [details] This file doesn't work properly with the latest upgrade of calc
Resetting my profile didn't make any difference.
PgUp/Down looks good for me, but I see delay when click on "Standing" sheet. Works smoothly in version 4.2.8.2-> marking as regression. Win7; Version: 6.0.0.0.alpha0+ Build ID: c7fe625c8d41f648f89765abc40bb7b8fd4ed12a CPU threads: 1; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-07-16_02:04:02 looks like win only bug, no repro on Linux master.
This seems to have begun at the below commit. Adding Cc: to Khaled Hosny; Could you possibly take a look at this one? Thanks 19490574e42c3180a38d55ccbbf1e3a00802150d is the first bad commit commit 19490574e42c3180a38d55ccbbf1e3a00802150d Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Tue Mar 7 03:23:53 2017 -0800 source a51b7a1c3a7e7cf7b0c733e1dec40288278c1884 author Khaled Hosny <khaledhosny@eglug.org> 2017-03-03 03:15:14 (GMT) committer Khaled Hosny <khaledhosny@eglug.org> 2017-03-03 13:22:53 (GMT) commit a51b7a1c3a7e7cf7b0c733e1dec40288278c1884 (patch) tree 6452088195b6c0ad617e7a6b9f97ecc8672d321e parent 5742868ccf030b2c0f03538d030bd18bd5666bdb (diff) tdf#103831, tdf#100986: Force using GDI when needed
(In reply to raal from comment #6) > This seems to have begun at the below commit. > Adding Cc: to Khaled Hosny; Could you possibly take a look at this one? > Thanks > > 19490574e42c3180a38d55ccbbf1e3a00802150d is the first bad commit > commit 19490574e42c3180a38d55ccbbf1e3a00802150d > Author: Norbert Thiebaud <nthiebaud@gmail.com> > Date: Tue Mar 7 03:23:53 2017 -0800 > > source a51b7a1c3a7e7cf7b0c733e1dec40288278c1884 > author Khaled Hosny <khaledhosny@eglug.org> 2017-03-03 03:15:14 (GMT) > committer Khaled Hosny <khaledhosny@eglug.org> 2017-03-03 13:22:53 (GMT) > commit a51b7a1c3a7e7cf7b0c733e1dec40288278c1884 (patch) > tree 6452088195b6c0ad617e7a6b9f97ecc8672d321e > parent 5742868ccf030b2c0f03538d030bd18bd5666bdb (diff) > tdf#103831, tdf#100986: Force using GDI when needed The problem is the incomplete DirectWrite renderer and I don't think Khaled wants to get into that.
*** Bug 112307 has been marked as a duplicate of this bug. ***
*** Bug 107770 has been marked as a duplicate of this bug. ***
IT is difficult for me to understand if this is the same problem I described in some posts on Bug 107521, and discussed in a more general fashion in bug 106990. To me this occurs in a more widespread fashion, not exclusively with pag down and up keys, even though it is clearly evident in that case. It happens also with brand new files, not only old ones; It depends on the thickness of data displayed on the sheet - if the sheet if filled up with data, the slowdown will be worse. As I wrote there, it can be up to 13 times slower than it was in LO 5.3.1. And finally the keyboard buffer rapidly fills so that the user loses actual control of what is happening in the sheet scrolling action.
I confirm that the delay does not affect LO 5.2.7.2 64 bits, despite the fact that it reports that the OpenGL is not active. Versions 5.3.4.2, 5.3.6.1, 5.4.0, 5.4.1.2 64 bits are all affected by the delay, according to the tests with spreadsheets edited in LO 5.2.7.2. Active graphical options: hardware acceleration, anti-aliasing, OpenGL for all rendering. Nevertheless all versions reported that the OpenGL was inactive.
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, no delay with paging or changing tabs. 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 =-testing-= Windows 10 Ent 64-bit en-US with Version: 5.3.7.0.0+ (x64) Build ID: 149f28e9a5d66db18ffb36547b2ba394c303fc4d CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; TinderBox: Win-x86_64@62-TDF, Branch:libreoffice-5-3, Time: 2017-09-30_08:04:07 Locale: en-US (en_US); Calc: CL 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
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.
Hello... I am sorry to bother... practically, on which release of 5.4 can we try and check this very good news???
*** Bug 112901 has been marked as a duplicate of this bug. ***
Same problem here with LO 5.3.6.1 after upgrading from LO 5.2.5 Win 7 32bit Tools -> Options -> View -> "Use OpenGL for all rendering" Checked "Ignore OpenGL blacklist" Unchecked "GL is currently disabled." The redraw is slow even when I switch between programs.
I've just noticed this with Version: 5.4.2.2 (64-bit) on macOS High Sierra 10.13 with 8GB RAM and an SSD (2016 13" MBP). It seemed more noticeable after upgrading from an older release (before 5.3.6). * It doesn't happen with Writer. * All other applications closed to test it wasn't them hogging memory. * Scroll lag occurs on blank Calc sheets (both in safe mode and normal mode, reset of profile also seemed to change nothing). * OpenGL enabled or disabled seems to make no difference (default is disabled) * Antialiasing settings seem to make no difference. * I tweaked the memory settings to double the default and noticed no change. Scrolling by one or two cells at a time is impossible - there's a delay between dragging on the trackpad and anything from happening; only larger scroll movements work. Limited settings are available for macOS with the trackpad. It's completely unresponsive with a slight drag in two finger scroll mode. And now, I've just uninstalled it and put 5.3.6.1 on. Scrolling down seems more unresponsive than scrolling up! In fact, scrolling up now appears possible by one cell at a time. Is it a (blank) cell population thing? CPU utilisation spikes in both directions according to Activity Monitor. I suppose the workaround right now is to do a big sweeping scroll motion down (or page down), followed by more incremental up scrolling. You really have to scroll at a fast speed to get it to move - dragging the fingers slowly to scroll down will never get it moving. Also checked my settings to ensure that it had nothing to do with the scroll direction settings (i.e., "natural" swipe to scroll vs conventional move fingers down to scroll). I notice the same effects if I Cmd+Down to the bottom of the sheet (row 1048576 - hiding most of the rows in the sheet hasn't helped either). Going up seems to present no issue with 5.3.6.1, but down is a struggle. Additionally, dialog boxes as well as the launcher are sluggish. Cmd+1 for Cell Properties always takes a couple of seconds to respond. Can others check if there's a difference in responsiveness for scrolling direction?
(In reply to rwcaret2 from comment #17) Please create a new bug report for his one. Thanks!
Ah whoops, I just found a more relevant report for this one. --> https://bugs.documentfoundation.org/show_bug.cgi?id=109062
Currently there's no way to enable the DirectWrite from the UI, thus closing as RESOLVED FIXED
Sorry but I not understand.... you mean this is "fixed" as it is now in LO 5.3.7, and will be in 5.4.xx (I asked about xx but nobody answered me) and 6.0? Am I correct? Thank you
(In reply to Andy from comment #21) > Sorry but I not understand.... you mean this is "fixed" as it is now in LO > 5.3.7, and will be in 5.4.xx (I asked about xx but nobody answered me) and > 6.0? > Am I correct? > Thank you Yes, it will be fixed in 5.4.3, 5.3.7 and 6.0
*** Bug 111333 has been marked as a duplicate of this bug. ***