Bug 113347 - Scrolling with the horizontal/vertical toolbar is sluggish with OpenGL enabled
Summary: Scrolling with the horizontal/vertical toolbar is sluggish with OpenGL enabled
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.4.0.3 release
Hardware: All Windows (All)
: medium normal
Assignee: Mike Kaganski
URL:
Whiteboard: target:6.0.0 target:5.4.4
Keywords: bibisected, perf, regression
: 113744 (view as bug list)
Depends on:
Blocks: DirectWrite Scrolling-Performance VCL-OpenGL
  Show dependency treegraph
 
Reported: 2017-10-22 13:28 UTC by Telesto
Modified: 2021-12-05 15:46 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Bibisect log (2.92 KB, text/plain)
2017-10-22 13:31 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2017-10-22 13:28:15 UTC
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
Comment 1 Telesto 2017-10-22 13:29:31 UTC
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
Comment 2 Telesto 2017-10-22 13:31:55 UTC
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.
Comment 3 m_a_riosv 2017-10-23 14:45:58 UTC
I think a dup.

*** This bug has been marked as a duplicate of bug 104716 ***
Comment 4 Telesto 2017-10-23 17:34:33 UTC
(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)
Comment 5 Telesto 2017-10-23 18:40:35 UTC
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.
Comment 6 Telesto 2017-10-31 08:19:12 UTC
Second example Writer (bisected it to the same commit)
1. Open attachment 137388 [details] (with OpenGL enabled)
2. Enable formatting marks
3. Scroll down
Comment 7 Commit Notification 2017-11-02 03:33:49 UTC
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.
Comment 8 Mike Kaganski 2017-11-02 06:58:24 UTC
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.
Comment 9 wickles 2017-11-02 18:42:56 UTC
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.
Comment 10 wickles 2017-11-02 19:00:43 UTC
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.
Comment 11 Telesto 2017-11-03 11:17:12 UTC
(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
Comment 12 Mike Kaganski 2017-11-03 11:24:42 UTC
Backport request to 5-4: https://gerrit.libreoffice.org/44253
Comment 13 V Stuart Foote 2017-11-03 14:28:39 UTC
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
Comment 14 V Stuart Foote 2017-11-03 15:40:05 UTC
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
Comment 15 V Stuart Foote 2017-11-03 15:41:56 UTC
s/bug 11385/bug 112385/
Comment 16 Commit Notification 2017-11-03 20:44:19 UTC
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.
Comment 17 Mike Kaganski 2017-11-04 13:50:58 UTC
Resolving FIXED based on comment 11.
Comment 18 Telesto 2017-11-05 09:19:44 UTC
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..
Comment 19 Mike Kaganski 2017-11-05 10:52:34 UTC
(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.
Comment 20 Aron Budea 2017-11-06 12:59:48 UTC
(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!
Comment 21 V Stuart Foote 2017-11-06 14:06:34 UTC
Windows only (comment 13) setting as such.
Comment 22 Mike Kaganski 2017-11-09 18:54:21 UTC
*** Bug 113744 has been marked as a duplicate of this bug. ***
Comment 23 Joel Lisenby 2017-11-09 19:04:25 UTC
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
Comment 24 Telesto 2017-11-09 20:12:10 UTC
(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