Bug 120360 - Draw extremely slow when table is added
Summary: Draw extremely slow when table is added
Status: VERIFIED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
6.0.0.0.alpha0+
Hardware: x86-64 (AMD64) All
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: haveBacktrace, perf, regression
Depends on:
Blocks: ImpressDraw-Tables
  Show dependency treegraph
 
Reported: 2018-10-06 07:47 UTC by Pim van Nierop
Modified: 2021-05-25 10:39 UTC (History)
5 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 Comment hidden (obsolete)
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
Comment 9 QA Administrators 2019-11-08 03:38:28 UTC Comment hidden (obsolete)
Comment 10 Roman Kuznetsov 2019-11-24 16:30:02 UTC
no repro in

Версия: 6.5.0.0.alpha0+ (x64)
ID сборки: 32dcf3f0fdafcf44457842a8aa4f54d30d856ca9
Потоков ЦП: 4; ОС:Windows 10.0 Build 17763; Отрисовка ИП: GL; VCL: win; 
Локаль: ru-RU (ru_RU); Язык интерфейса: ru-RU
Calc: threaded


Buovjaga, is it Linux only?
Comment 11 Buovjaga 2019-11-24 20:03:46 UTC
Roman: this is originally reported against Windows and I can still reproduce on Win. Are you sure you are testing like I mention in comment 1?

To be clear, I observe a slowness in selecting the table cells. Not as extreme as the reporter (5 seconds), but still very noticeable.

On Linux I repro with all VCL backends.

Version: 6.4.0.0.alpha1+ (x64)
Build ID: 7c6226bee72805db7f0e567ca9f06c786a7d0da2
CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; 
Locale: fi-FI (fi_FI); UI-Language: en-US
Calc: threaded

Arch Linux 64-bit
Version: 6.5.0.0.alpha0+
Build ID: b30251ca0d102ced36799ee18d4bbcd9e8530fa0
CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: kf5; 
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
Built on 22 November 2019
Comment 12 Timur 2021-05-18 11:27:45 UTC
I tried to test, but I couldn't clearly repro in older LO like 5.4 so maybe that's why this doesn't look like an issue to me in 7.2+. 
I close, but if anyone reproduces, feel free to set New. Just write a specific steps which take noticeable time, so that they can be tested with "time".
Comment 13 Buovjaga 2021-05-25 10:39:25 UTC
(In reply to Timur from comment #12)
> I tried to test, but I couldn't clearly repro in older LO like 5.4 so maybe
> that's why this doesn't look like an issue to me in 7.2+. 
> I close, but if anyone reproduces, feel free to set New. Just write a
> specific steps which take noticeable time, so that they can be tested with
> "time".

Yes, it seems the problem is gone

Version: 7.2.0.0.alpha1+ / LibreOffice Community
Build ID: 0bcc06b0a563da08ccf1704b2f51376f27f51f62
CPU threads: 8; OS: Linux 5.12; UI render: default; VCL: gtk3
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-05-23_18:42:59
Calc: threaded