Bug 120360 - Draw extremely slow when table is added
Summary: Draw extremely slow when table is added
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
6.0.0.0.alpha0+
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, haveBacktrace, perf, regression
Depends on:
Blocks: ImpressDraw-Tables
  Show dependency treegraph
 
Reported: 2018-10-06 07:47 UTC by Pim van Nierop
Modified: 2018-11-07 17:11 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
File with table that slows my system. (15.13 KB, application/vnd.oasis.opendocument.graphics)
2018-10-06 07:47 UTC, Pim van Nierop
Details
Callgrind output from master (1.20 MB, application/x-xz)
2018-10-31 19:05 UTC, Buovjaga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pim van Nierop 2018-10-06 07:47:43 UTC
Created attachment 145429 [details]
File with table that slows my system.

I experiences the same issue as someone on the forums and this problem makes use of draw impossible form me.

Problem: when inserting a table in to a .odg, Draw becomes extremely slow. With slow I mean that the GUI becomes unresponsive; it takes 5 sec. to select a different element in the image or select the contents of a table cell.

System:
Version: 6.1.2.1 (x64)
Build ID: 65905a128db06ba48db947242809d14d3f9a93fe
CPU threads: 4; OS: Windows 10.0; UI render: GL; 
Locale: en-US (en_US); Calc: group threaded

See attachment for same file.
Comment 1 Buovjaga 2018-10-31 18:37:45 UTC
Repro, typically by focusing after "Devonian" and dragging up and down to select cells.

It is a bit weird that I can repro this on Linux with gtk3_kde5, but not with gtk2, yet the bibisect result with win32-6.0 repo points to a Win-only commit:

https://gerrit.libreoffice.org/plugins/gitiles/core/+/50799a721c7ddcf9475a1b79984ed64ddd7cdf57%5E!
tdf#109997 WIN don't post a callback event directly

Adding Cc: to Jan-Marek Glogowski

jmux: does my bibisect result make any sense? I did checkout the previous commit to confirm it was good.
Comment 2 Jan-Marek Glogowski 2018-10-31 18:42:58 UTC
This is a Windows only patch, just touching a common header and code in vcl/win/.
Comment 3 Buovjaga 2018-10-31 18:56:37 UTC
I guess I will throw it up for auction again (hopefully someone on Linux can do it).
Comment 4 Buovjaga 2018-10-31 18:58:49 UTC
Note: the slowness is not extreme for me. It is just slower compared to older builds.
Comment 5 Buovjaga 2018-10-31 19:01:30 UTC
Slowness is also seen on Linux with gen backend. So gtk2 is the only one without the slowness.
Comment 6 Buovjaga 2018-10-31 19:05:09 UTC
Created attachment 146214 [details]
Callgrind output from master

Arch Linux 64-bit
Version: 6.2.0.0.alpha1+
Build ID: 45d8fb0ba77396b7d5e02c2fc9a8ae5b233a02bc
CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; 
Locale: fi-FI (fi_FI.UTF-8); Calc: threaded
Built on 31 October 2018
Comment 7 raal 2018-11-06 13:04:02 UTC
No repro Version: 6.2.0.0.alpha1+
Build ID: 2cef68a605494bcef0388201b1058c95788c45a8
CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win;
Comment 8 Buovjaga 2018-11-07 17:11:31 UTC
(In reply to raal from comment #7)
> No repro Version: 6.2.0.0.alpha1+
> Build ID: 2cef68a605494bcef0388201b1058c95788c45a8
> CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win;

Still laggy with the selection. Confirmed in Safe mode as well.

Arch Linux 64-bit
Version: 6.2.0.0.alpha1+
Build ID: dbe94dd3b64e74f661ea7193d8e06ac91f1dd7b0
CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; 
Locale: fi-FI (fi_FI.UTF-8); Calc: threaded
Built on 7 November 2018