Bug 96176 - DRAW: Slow performance zooming an SVG after opening
Summary: DRAW: Slow performance zooming an SVG after opening
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: haveBacktrace, perf, regression
Depends on:
Blocks: SVG-Import Draw-Images
  Show dependency tree / graph
 
Reported: 2015-12-01 10:59 UTC by Xisco Faulí
Modified: 2022-06-12 01:32 UTC (History)
8 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
View All 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 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.
Comment 13 QA Administrators 2019-07-01 02:46:49 UTC Comment hidden (obsolete)
Comment 14 Xisco Faulí 2019-07-01 09:15:40 UTC 
still reproduced in

Version: 6.4.0.0.alpha0+
Build ID: 9fbedb7929936a45967ae49bc15b985f95e2ebd3
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded
Comment 15 QA Administrators 2021-07-01 04:05:31 UTC Comment hidden (obsolete)
Comment 16 Roman Kuznetsov 2021-12-07 14:28:49 UTC 
No problem with the SVG file in

Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 3a61cce54277fd12570103a191c50d9b37ef3dd3
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: ru-RU
Calc: threaded

I see only 8-9% of CPU usage when I try change the scale with a mouse wheel

Xisco, Buovjaga, please retest it too
Comment 17 Buovjaga 2021-12-07 14:31:51 UTC 
Yeah, I actually tested it, but I think Xisco should make the decision. If the observed performance is good, I don't think we should focus on the CPU use only.
Comment 18 Xisco Faulí 2021-12-13 13:11:00 UTC 
yep, it's pretty smooth in

Version: 7.3.0.0.beta1+ / LibreOffice Community
Build ID: ecfb83d7463bed7c89baeccc03286c1ac9956d70
CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Closing