Bug 132207 - Scrolling a selected table with lots of cells slow (comment 3)
Summary: Scrolling a selected table with lots of cells slow (comment 3)
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.0.0.3 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, perf, regression
Depends on:
Blocks:
 
Reported: 2020-04-17 20:29 UTC by Telesto
Modified: 2020-09-25 06:42 UTC (History)
2 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 Telesto 2020-04-17 20:29:37 UTC 
Description:
Undo large table takes long time

Steps to Reproduce:
1. Open attachment 159667 [details]
2. CTRL+A
3. CTRL+X
4. CTRL+Z -> Monitor CPU

Actual Results:
10-15 seconds cpu utilazation

Expected Results:
Probably not?


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.0.0.0.alpha0+ (x64)
Build ID: 4475bcd83aac7e033fc5250f268eb922bd471e7b
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win; 
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: CL
Comment 1 Bart 2020-05-02 12:55:52 UTC 
With Linux/Debian10 and LibreOffice versions 6.1 through 7.0, Ctl-Z took 2 to 8 seconds. 

LibreOffice version:
   6.1 : 8 seconds
   6.3 : 2 seconds
   6.4 : 2 seconds
   7.0 : 2 seconds

					~~~

   Here are the versions that I used:

Version: 6.1.5.2
Build ID: 1:6.1.5-3+deb10u5
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk2; 
Locale: en-US (en_US.UTF-8); Calc: group threaded

Version: 6.3.4.1
Build ID: a21169d87339dfa44546f33d6d159e89881e9d92
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk2; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

Version: 6.4.3.2
Build ID: 747b5d0ebf89f41c860ec2a39efd7cb15b54f2d8
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

Version: 7.0.0.0.alpha0+
Build ID: 4d03bd252274308f64332e7c0523068c38ac684a
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-04-26_05:59:56
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 2 Xisco Faulí 2020-05-06 10:35:06 UTC 
(In reply to Bart from comment #1)
 
> LibreOffice version:
>    6.1 : 8 seconds
>    6.3 : 2 seconds
>    6.4 : 2 seconds
>    7.0 : 2 seconds

it seem quite fast to me.

@Telesto, could you please test with an older version and without skia ?
Comment 3 Telesto 2020-07-03 17:53:03 UTC 
45 seconds with
Version: 7.1.0.0.alpha0+ (x64)
Build ID: c48e4d795e37f23b71d647247590807ab9e52223
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 4 Telesto 2020-07-03 18:07:35 UTC 
Sorry 10 seconds.. 
The slowness is more related to selection of the full table + scroll (that really slow part)

Above found in
7.1

6.0

but not in
Versie: 5.2.4.2 
Build ID: 3d5603e1122f0f102b62521720ab13a38a4e0eb0
CPU Threads: 4; Versie besturingssysteem:Windows 6.2; UI Render: standaard; 
Locale: nl-NL (nl_NL); Calc: CL


-> Hope you don't mind recycling this bug
Comment 5 Dieter 2020-09-25 06:42:38 UTC 
Telesto, what happens, if you test without Skia as requested in comment 2?