Bug 96176 - DRAW: Slow performance zooming an SVG after opening
Summary: DRAW: Slow performance zooming an SVG after opening
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, haveBacktrace, perf, regression
Depends on:
Blocks: SVG-Import Draw-Images
  Show dependency treegraph
 
Reported: 2015-12-01 10:59 UTC by Xisco Faulí
Modified: 2018-06-30 19:39 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Callgrind output from master (5.88 MB, application/x-xz)
2018-05-19 16:55 UTC, Buovjaga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Xisco Faulí 2015-12-01 10:59:22 UTC
Slow performance opening and editing a file

Steps to reproduce:
1. Open attachment 120918 [details]

Observed behavior: Compared to previous versions, Draw takes longer to open the file. Besides, it becomes unusuable when scrolling or  editing the file.

Notes:
- Same behavior observed whether OpenCL is enabled or disabled.

- Issue not reproduced in:

Version: 5.0.2.2
Build ID: 37b43f919e4de5eeaca9b9755ed688758a8251fe
Locale: es-ES (es_ES)

on the same machine
Comment 1 Buovjaga 2015-12-04 19:47:02 UTC
Not reproduced. Opens immediately and after zooming in, scrolling and manipulating does not make it go slow.

I guess you could test with the most recent build.

Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+
Build ID: 81fa5340191baf8687f9c82f1f414f5afc86b529
Threads 4; Ver: Windows 6.1; Render: default; 
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-12-03_21:19:19
Locale: fi-FI (fi_FI)
Comment 2 Xisco Faulí 2015-12-09 10:08:17 UTC
Hi Beluga,

Just tried with

Version: 5.2.0.0.alpha0+
Build ID: 6fd3f3caad1a559165dc9332249cbd0d84930775
Threads 4; Ver: Windows 6.1; Render: GL; 

TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-12-08_23:31:11
Locale: es-ES (es_ES)

and CPU usage goes to 30% when zooming in/out with a i7 2.60 GHz
Comment 3 Buovjaga 2015-12-13 14:34:56 UTC
(In reply to Xisco Faulí from comment #2)
> and CPU usage goes to 30% when zooming in/out with a i7 2.60 GHz

Peak CPU for me is 24% when zooming in/out. Most of the time stays below 20%.
Lenovo Thinkpad T520 from 2012.

Version: 5.2.0.0.alpha0+
Build ID: 917d59a84124d1022bd1912874e7a53c674784f1
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-12-12_12:17:04
Locale: fi-FI (fi_FI)
Comment 4 Robinson Tryon (qubit) 2015-12-14 05:32:37 UTC Comment hidden (obsolete)
Comment 5 A (Andy) 2015-12-26 20:17:28 UTC
Reproducible with LO 5.1.0.1, Win 8.1

It takes about 4 to 5 seconds to open the file and it hangs again and again if I try to scroll it up and down (no smooth scrolling, it is jumping).  When zooming in and out it takes always some seconds and the CPU usage goes up to 30% to 45% (Intel Pentium).  When zooming the image/file content in the Internet Explorer I experience no real delay.
Comment 6 raal 2015-12-31 11:34:54 UTC
Seems to be fixed, tested with bibisect-win32-5.2 repo and bug occurs in oldest version (~25% CPU load continuously), but not in latest version (about week old)  - 0 CPU load. Please could you retest with actual 5.2?
Version: 5.2.0.0.alpha0+
Build ID: f4e703aa39e9c294441b6dd86189d8aff32db8bf
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default;
Comment 7 Buovjaga 2016-01-02 15:56:21 UTC
(In reply to raal from comment #6)
> Seems to be fixed, tested with bibisect-win32-5.2 repo and bug occurs in
> oldest version (~25% CPU load continuously), but not in latest version
> (about week old)  - 0 CPU load. Please could you retest with actual 5.2?
> Version: 5.2.0.0.alpha0+
> Build ID: f4e703aa39e9c294441b6dd86189d8aff32db8bf
> CPU Threads: 4; OS Version: Windows 6.1; UI Render: default;

You tried the back and forth zooming? I still get a CPU core to max out.

Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+
Build ID: b4082bed2de12cd576a06a9f456a71101809f3ed
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-01-02_00:47:38
Locale: fi-FI (fi_FI)
Comment 8 Telesto 2016-12-18 13:42:37 UTC
Confirming: Peak CPU for me is 24% when zooming in/out. Most of the time stays below 20%.
Version: 5.4.0.0.alpha0+
Build ID: 53edf60c4ce6ed32f87471e018878c40b788005a
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-12-18_06:57:59
Locale: nl-NL (nl_NL); Calc: CL

also in 
Versie: 4.4.6.3 
Build ID: e8938fd3328e95dcf59dd64e7facd2c7d67c704d
Locale: nl_NL

also in
Version: 4.3.0.4
Build ID: 62ad5818884a2fc2e5780dd45466868d41009ec0

and in
Versie: 4.1.0.4 
Build ID: 89ea49ddacd9aa532507cbf852f2bb22b1ace28

and in
Versie 4.0.0.3 (Bouw-id: 7545bee9c2a0782548772a21bc84a9dcc583b89)

Seems better in:
LibreOffice 3.5.7.2 
Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
Comment 9 QA Administrators 2018-02-08 03:35:49 UTC Comment hidden (obsolete)
Comment 10 Buovjaga 2018-05-18 19:34:29 UTC
Still repro.

Version: 6.1.0.0.alpha1+ (x64)
Build ID: 8c07193cec5e09d50b20bc5b107da02a7d8f05a5
CPU threads: 4; OS: Windows 10.0; UI render: default; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-05-17_23:03:56
Locale: fi-FI (fi_FI); Calc: group
Comment 11 Buovjaga 2018-05-19 16:55:25 UTC
Created attachment 142209 [details]
Callgrind output from master

Zooming in and out

Arch Linux 64-bit
Version: 6.1.0.0.alpha1+
Build ID: 21b11273ae91f0cf7fd5f3f9fd2168e4349852c4
CPU threads: 8; OS: Linux 4.16; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on May 11th 2018
Comment 12 Buovjaga 2018-06-30 19:06:35 UTC
I tried bibisecting the zoom in & out thing, but the CPU % used are so close to each other and the method is so unscientific that it was impossible to get a worthy result. I actually got a result that a commit "was both good and bad".

Thus I don't know if it makes sense to keep the request to bibisect as the other problems are gone anyway.