Description: Scrolling with the horizontal/vertical toolbar is sluggish with OpenGL enabled Steps to Reproduce: 1. Open attachment 137051 [details] 2. Move the horizontal/vertical by left clicking the scroll bar and moving it Actual Results: Slow (bumpy) scrolling Expected Results: Smooth scrolling Reproducible: Always User Profile Reset: No Additional Info: Found in 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: nl-NL (nl_NL); Calc: CL User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
OpenGL info: DriverVersion: 22.19.162.4 DriverDate: 4-24-2017 DeviceID: PCI\VEN_1002&DEV_683D&SUBSYS_25561458&REV_00 AdapterVendorID: 0x1002 AdapterDeviceID: 0x683d AdapterSubsysID: 0x25561458 DeviceKey: System\CurrentControlSet\Control\Video\{D04B9806-9C1D-4DD9-A969-0AC17C8ABE12}\0000 DeviceString: AMD Radeon HD 7700 Series
Created attachment 137203 [details] Bibisect log Note: Slow scrolling is only happening in a text area; not with empty cells 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.
I think a dup. *** This bug has been marked as a duplicate of bug 104716 ***
(In reply to m.a.riosv from comment #3) > I think a dup. > > *** This bug has been marked as a duplicate of bug 104716 *** I think not. Bug 104716 is about: (a) a Writer document (not Calc) (b) with big/complex(PNG)images (c) with or without OpenGL enabled (d) the bug is older than this one (should be introduced around 2017-07-21, if my bibisect is correct)
The cygwin terminal is also flooding with this when scrolling around with OpenGL enabled: warn:vcl.gdi:5420:5816:vcl/win/gdi/winlayout.cxx:86: Binding of font failed. The font might not be supported by DirectWrite.
Second example Writer (bisected it to the same commit) 1. Open attachment 137388 [details] (with OpenGL enabled) 2. Enable formatting marks 3. Scroll down
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=11459949e920fab6074bab85e3e1a748e9aee1ee Related: tdf#113347: properly check HRESULT value It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I don't know if the problem is actually caused by this, but we had a wrong code causing those "warn:vcl.gdi:5420:5816:vcl/win/gdi/winlayout.cxx:86: Binding of font failed. The font might not be supported by DirectWrite" warnings, that prevented caching of glyphs, which really could impair performance. Testing with daily and posting feedback is welcome.
I am also experiencing this problem. LO was very snappy on Win 8.1 64 until upgrading to Win 10 recently. I experience the slow scrolling with OpenGL enabled; it's quite a bit better with OGL disabled, but I would say still not perfect. I also have a spreadsheet that takes a while to load, and noticeably lags cursor motion while loading, with or without OGL enabled. I will try the daily build and see if it helps. Thanks.
It is still very slow for me with OpenGL enabled, and much better with OGL disabled, on LO Dev Version: 6.0.0.0.alpha1+ (x64) Build ID: 1f8c3e3b78e0abb96d06a51eca354ae7ade5deb2 CPU threads: 4; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2017-11-02_00:30:21 Locale: en-US (en_US); Calc: CL However this looks like an older commit, I will test again once the new build is available.
(In reply to Mike Kaganski from comment #8) > I don't know if the problem is actually caused by this, but we had a wrong > code causing those "warn:vcl.gdi:5420:5816:vcl/win/gdi/winlayout.cxx:86: > Binding of font failed. The font might not be supported by DirectWrite" > warnings, that prevented caching of glyphs, which really could impair > performance. > > Testing with daily and posting feedback is welcome. Thanks Mike! Working like a charm :-). A backport would be nice! Version: 6.0.0.0.alpha1+ Build ID: 06cad1a9a42ea74434f9ed0e4027163d029eb4a1 CPU threads: 4; OS: Windows 6.3; UI render: GL; TinderBox: Win-x86@42, Branch:master, Time: 2017-11-02_23:40:06 Locale: nl-NL (nl_NL); Calc: CL
Backport request to 5-4: https://gerrit.libreoffice.org/44253
The bibisect and Mike's patch are Windows only DirectWrite in use now [1] just with OpeGL. With no other repro, Linux or macOS builds--so Windows only. And maybe source of anecdotal complaints of slowness with OpenGL from Windows users. =-ref-= [1] https://gerrit.libreoffice.org/#/c/42897
Hmm, working with today's TB 42 build with this tweak of the DWriteTextRenderer we seem to be getting better OpenGL glyph rendering as well, and the clipping of bug 113277 and bug 11385 seems resolved. =-testing-= Windows 10 Home 64-bit en-US with HD Graphics 620 (22.20.16.4815) with Version: 6.0.0.0.alpha1+ (x64) Build ID: 8c374022790b54834fa54615e1953c8ee30641a8 CPU threads: 4; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2017-11-03_01:58:27 Locale: en-US (en_US); Calc: group
s/bug 11385/bug 112385/
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-5-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=de811bb2359757b90a0a9851963bd8702b97dab0&h=libreoffice-5-4 Related: tdf#113347: properly check HRESULT value It will be available in 5.4.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Resolving FIXED based on comment 11.
Is it still possible to get this patch into 5.4.3? Would be nice. There seems to be a .3 build. The issue is prominent for very one using OpenGL and it's enabled by default, so..
(In reply to Telesto from comment #18) > Is it still possible to get this patch into 5.4.3? Would be nice. There > seems to be a .3 build. I asked about it at the time it was pushed to 5-4, and got the reply from cloph: > [20:46:51 UTC] cloph: yeah, that's right - did a -hotfix1 one to get https://gerrit.libreoffice.org/#/c/44211/ in, but now builds are running/don't plan to redo unless it really is a stopper. So - I don't know of other .3 builds. But if you have some information, you are welcome to cherry-pick the 5-4 patch in gerrit.
(In reply to Telesto from comment #18) > Is it still possible to get this patch into 5.4.3? Would be nice. There > seems to be a .3 build. > The issue is prominent for very one using OpenGL and it's enabled by > default, so.. Added Christian to CC, let's see if he has anything to say. Btw, this fix also fixed a bunch of UI font clipping issues: bug 113277, bug 111307 and bug 112385. Nice job!
Windows only (comment 13) setting as such.
*** Bug 113744 has been marked as a duplicate of this bug. ***
I have captured a video of the choppy scrolling if it helps. Also, for me this effect occurs with or without OpenGL enabled and is in fact worse without OpenGL. Video: https://youtu.be/4QlD9reW4f8 See bug 113744 to download the csv used in the video. System: Windows 10 Pro, Build 16299.19 with latest updates installed. CPU: Intel i7 6700 RAM: 16GB GPU: AMD RX480, Radeon Software Version 17.11.1 Version: 5.4.2.2 (x64) Build ID: 22b09f6418e8c2d508a9eaf86b2399209b0990f4 CPU threads: 8; OS: Windows 6.19; UI render: default; Locale: en-US (en_US); Calc: CL
(In reply to Joel Lisenby from comment #23) The non-OpenGL issue is fixed in LibreOffice 5.4.3. And to OpenGL one will be fixed in 5.4.4