Bug 93255 - DOCX - Performance regression in browsing document
Summary: DOCX - Performance regression in browsing document
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.1.0.0.alpha0+ Master
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: perf
Depends on:
Blocks:
 
Reported: 2015-08-07 21:08 UTC by Yousuf Philips (jay) (retired)
Modified: 2016-03-19 14:25 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2015-08-07 21:08:47 UTC 
Steps:
1) Open attachment 117718 [details]
2) Scroll through page 1 using the mouse scrollwheel, as other pages are not visible due to bug 82452
3) Notice the lag.
4) Click in different areas of page 1 and notice that the mouse cursor will take 2 to 3 seconds for it to appear in that location (atleast thats how long it takes on my pc)

The mouse scrolling is smooth in 5.0 daily, so that is a regression. The slow movement of the cursor seems to be OOo inherited, though it could be related to the table problem in bug 82452.

Version: 5.1.0.0.alpha1+
Build ID: 25534a62b2ba398c6298c6b9e521f20de1087540
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-08-07_14:13:33
Locale: en-US (en_US.UTF-8)

Version: 5.0.1.0.0+
Build ID: 34bdbdee3baebf5f008f2ad6762f455db7752e48
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:libreoffice-5-0, Time: 2015-08-07_13:05:59
Locale: en-US (en_US.UTF-8)
Comment 1 Jan Holesovsky 2015-08-12 12:34:37 UTC 
Looks to me as a difference between the gtk2 and gtk3 vclplug performance; with export SAL_USE_VCLPLUGIN=gtk I see normal behaviour in master, but with export SAL_USE_VCLPLUGIN=gtk3, the lag is very considerable.

I did not have a non-dbgutil build at hand to actually profile that, though :-(
Comment 2 Yousuf Philips (jay) (retired) 2015-10-05 03:27:35 UTC 
Setting to confirmed using Kendy's comment.
Comment 3 Robinson Tryon (qubit) 2015-12-09 18:08:10 UTC 
Migrating Whiteboard tags to Keywords: (perf)
Comment 4 Caolán McNamara 2016-03-17 16:05:27 UTC 
Is this lag still a problem with the latest 5.1 ? I'm not seeing it FWIW
Comment 5 Yousuf Philips (jay) (retired) 2016-03-18 07:17:21 UTC 
Mouse scrolling seems to be fine now, while the 2 or 3 second delayed mouse cursor is still present.

Version: 5.1.1.3
Build ID: 89f508ef3ecebd2cfb8e1def0f0ba9a803b88a6d
CPU Threads: 2; OS Version: Linux 4.2; UI Render: default; 
Locale: en-US (en_US.UTF-8)

Version: 5.2.0.0.alpha0+
Build ID: 053103915717e41436b7a397d9cfa3ea0e3519cc
CPU Threads: 2; OS Version: Linux 4.2; UI Render: default; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-03-11_12:52:46
Locale: en-US (en_US.UTF-8)
Comment 6 Caolán McNamara 2016-03-18 11:25:19 UTC 
So that suggests that the regression is fixed and what remains is an inherited from OOo problem, right ? Maybe we should close this one then because of the use of regression in the title and so on and if needs be create another for the specific mouse click delay thing which is not gtk2 vs gtk3 specific.
Comment 7 Michael Meeks 2016-03-18 12:01:37 UTC 
Sounds good to me; lets file a separate issue for the cursor bits - in fact vcl::Cursor handling is some pretty horribly awful code in LibreOffice I'm afraid - from any perspective =)