Bug 107355 - Slow spreadsheet redraw speed since 5.3 (DirectWrite)
Summary: Slow spreadsheet redraw speed since 5.3 (DirectWrite)
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
Keywords: perf
Depends on:
Blocks: DirectWrite-Regression
  Show dependency treegraph
Reported: 2017-04-22 18:24 UTC by joshas
Modified: 2017-10-18 11:16 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:
Regression By:

sample document (81.46 KB, application/zip)
2017-04-22 21:07 UTC, joshas
ODS test file for slow display speed (3.95 MB, application/vnd.oasis.opendocument.spreadsheet)
2017-07-13 17:18 UTC, AnFr
simple example - low size file (240.74 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-07-14 15:12 UTC, AnFr

Note You need to log in before you can comment on or make changes to this bug.
Description joshas 2017-04-22 18:24:31 UTC
I have a spreadsheet that has quite a lot of data, to fill full screen width and several pages in height. Some minor formatting is used, as bold text and background colors for one column. No calculations are used at all, it's only simple formatted data.
When scrolling with scrollbar there is noticeable lag before redraw. Scrolling is not smooth. There are no problems with scrolling when there's no data in sheet.
Also, after restoring minimized window it takes a second or two to draw main spreadsheet data, system UI (menus, toolbars) appear instantly.
Hardware acceleration and OpenCL is not used.

Steps to Reproduce:
1. Open worksheet with a lot of data to fill the screen.
2. Try scrolling sheet using scrollbar.
3. Try minimizing and maximizing Calc window.

Actual Results:  
Laggy scrolling and slow redraw.

Expected Results:
Smooth scroll and instant redraw.

Reproducible: Always

User Profile Reset: Yes

Additional Info:
Automatic spellchecking is disabled, same issues occur when running in safe mode. Problems started a few versions ago, probably since 5.3 release.

User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0
Comment 1 Xisco Faulí 2017-04-22 20:06:29 UTC Comment hidden (obsolete)
Comment 2 joshas 2017-04-22 21:07:17 UTC
Created attachment 132756 [details]
sample document

I've attached first sample document I could find on the net, it still has same issues as my spreadsheet.
Comment 3 Xisco Faulí 2017-04-22 21:23:42 UTC Comment hidden (obsolete)
Comment 4 joshas 2017-04-23 07:12:27 UTC
I see same issues when running in safe mode. Just tested older version 5.2.6, from portable installation, and it performs much better.
Comment 5 Telesto 2017-04-23 15:47:17 UTC
Confirming with:
Build ID: 4354f0e9ef4a5538729a2a6f2d1745e247f6c5cd
CPU threads: 4; OS: Windows 6.19; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-04-21_06:05:57
Locale: nl-NL (nl_NL); Calc: CL

and - related to comment 4 - not with:
Build ID: a4d4fbeb623013f6377b30711ceedb38ea4b49f8
CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; 
TinderBox: Win-x86@62-merge-TDF, Branch:libreoffice-5-2, Time: 2016-12-24_14:43:55
Locale: nl-NL (nl_NL); Calc: CL
Comment 6 m.a.riosv 2017-04-23 23:41:01 UTC
Please test disabling Menu/Tools/Automatic spell checking.
Comment 7 AnFr 2017-07-13 17:18:45 UTC
Created attachment 134619 [details]
ODS test file for slow display speed

the slow Display speed I've detected on bigger Tables. (s. example)

The easy Test is to press 'Strg + End' ('Strg + Ende' on German Keyboard) and wait after the position is on display press 'Strg + Home' ('Strg + Pos1' on German Keyboard).

Since LibreOffice 5.3 the display speed is much slower than on LibreOffice 5.2 and before.

The attached example document has one table of the size 100 columns and 2000 rows.

Comment 8 AnFr 2017-07-14 15:12:41 UTC
Created attachment 134629 [details]
simple example - low size file


I've added a low size file to that shows the same behavior than the previous one.

With Kind Regards,
Comment 9 m.a.riosv 2017-07-14 15:19:17 UTC
Visible also in:
Build ID: 2f2eba56d1f8ec5cdcadb4852e8856858477c008
CPU threads: 4; OS: Windows 6.19; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-07-09_10:12:58
Locale: es-ES (es_ES); Calc: group
Comment 10 AnFr 2017-07-17 14:42:54 UTC
Info: The slow redraw 'speed' is Tool setting independent. "Automatic Spell Checking" and "AutoInput" active or inactive results into the same behavior.
Comment 11 AnFr 2017-07-18 10:13:57 UTC
In portable versions:

BUG not confirmed:

Build-ID: e80a0e0fd1875e1696614d24c32df0f95f03deb2
CPU-Threads: 4; BS-Version: Windows 6.1; UI-Render: Standard; Layout-Engine: neu; 
Gebietsschema: de-DE (de_DE); Calc: group

First time confirmed in:

Build-ID: 6cd4f1ef626f15116896b1d8e1398b56da0d0ee1
CPU-Threads: 4; BS-Version: Windows 6.1; UI-Render: Standard; Layout-Engine: neu; 
Gebietsschema: de-DE (de_DE); Calc: group

Comment 12 LPC 2017-07-22 09:51:48 UTC
This bug appeared at the same time this "feature" where the whole user interface gets anti-aliased and no option will change that. All redraw is super slow compared to non-anti-aliased version ( ? and confirmed with portable, especially so in big files.
Enabling Hardware acceleration and OpenGL seem to alleviate a bit of this slowness but still very slow. When I press a menu option I can see the grey rectangle before the text appears on top, this didn't happen in previous versions. In some sheets I can see each cell's format being changed one by one.
Disabling auto-correct etc doesn't help.

I can confirm this problem in x64 Windows 8.1, the previously installed version didn't suffer from this but can't remember which version it was (is there a cumulative LO install log?)

Just installed x64 and it looks almost as fast as Still some anti-aliasing going on (perhaps an OpenGL option in the driver?) and OpenGL is in use although tickbox is deselected on restart as reported in https://bugs.documentfoundation.org/show_bug.cgi?id=108533
Comment 13 Martin 2017-08-10 14:55:08 UTC

I got this Big Data effect with slow down and annoying speedloss also.
(35000 rows and 64 Columns mixed data, text and numbers, 3 to 5 sheets in one ODS file)

I filled up the sheets with simple formatted Data, no formula, only to sort the columns for creating clean CSV files. This is a great function of libre Office calc also the field formatting I love.

1. First I killed all automatic spellchecking, this helped ... I was thinking for a moment ... very good.

Then I go ahead with editing and like joshas speek, the scolling gots crazy.

2. I pressed the down key to step line by line ... no effect or extremly slow.

3. Then I checked the mouse on the right slider, and this was a big mistake. Then the table was fully grey no fillings and the slider on right side constantly jumps slowly, I guess page by page, unvisible up or down depends on the direction I clicked before.
After 5 Minutes I killed the task. Good luck no data loss. 

I repeated, after restart, my checks, but now I give up.
The saving of the sheets shows in the same way big loss of speed.

Doing the same work in MS Excel, I can run additional functions, macros and VBA scripts without any bad effect like this. 

I hope you will find the solution ....

Here the details to the software:
Version: (x64)
Build ID: 3d9a8b4b4e538a85e0782bd6c2d430bafe583448
CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; 
Locale: en-US (en_US); Calc: group
Comment 14 AnFr 2017-09-26 13:36:26 UTC

because of the significant performance loss this BUG needs a much higher classification.
For Info: In our company it is classified as show stopper, so no update to 5.3.x or higher will be done till BUG is fixed.

Comment 15 Telesto 2017-10-03 17:44:50 UTC Comment hidden (obsolete)
Comment 16 Timur 2017-10-04 07:25:12 UTC Comment hidden (obsolete)
Comment 17 Xisco Faulí 2017-10-04 20:57:05 UTC
This is a problem in DirectWrite, thus it's not fixed. My commit only changes the behaviour to use GDI instead, as it was before. The plan is to move to DirectWrite at some point. Keeping it open.
Comment 18 Xisco Faulí 2017-10-18 09:24:39 UTC
*** Bug 113158 has been marked as a duplicate of this bug. ***
Comment 19 Xisco Faulí 2017-10-18 11:16:08 UTC
Currently there's no way to enable the DirectWrite from the UI, thus closing as