Bug 59547 - VIEWING: Scrolling performance slow in RTF with large number of frames
Summary: VIEWING: Scrolling performance slow in RTF with large number of frames
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium major
Assignee: Not Assigned
URL:
Whiteboard: confirmed:4.3.0.0a0+:OSX
Keywords: filter:rtf, perf
Depends on:
Blocks: Frame Scrolling-Performance
  Show dependency treegraph
 
Reported: 2013-01-18 07:58 UTC by Timon
Modified: 2023-12-06 13:08 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file with hign CPU use while scrolling (9.90 KB, application/zip)
2013-01-18 07:58 UTC, Timon
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Timon 2013-01-18 07:58:01 UTC
Created attachment 73233 [details]
Example file with hign CPU use while scrolling

LibO Version 4.0.0.1 (Build ID: 527dba6f6e0cfbbc71bd6e7b88a52699bb48799) on Windows XP SP3 Russian

RTF is opened, but if we try to scroll down document to the second page, everything freezes. While scrolling CPU use jumps from 50% to 100% on Pentium Dual-Core CPU E5300 @ 2.60 GHz with 2 Gb of RAM (only LibO is launched on computer). If we stop trying to scroll through a document, CPU use drops significantly to 10% or even less after some time. The more pages contains document, more freezes we see.

Apache Open Office 3.4.1 Writer AOO 3.4.1m1 (Build: 9593) - Rev. 1372282  open and scroll this document in any direction with significantly fewer delays (CPU use jumps max to 50% and rapidly falls to zero) on Russian Windows XP Professional SP3 (32bit)
Comment 1 Joel Madero 2013-01-23 18:14:36 UTC
Verified on 3.6.3.2 - changing version to reflect this.

Marking as:
New (confirmed)
Major (major CPU usage, slows down entire system)
Medium (default for major, I think because this is rtf which isn't affecting many users, loweing to Medium is appropriate).


Thanks for reporting
Comment 2 Jean-Baptiste Faure 2013-08-16 18:12:51 UTC Comment hidden (obsolete)
Comment 3 Owen Genat (retired) 2014-01-10 09:58:32 UTC
(In reply to comment #2)
> The table is not a true table but is build by joining frames. 
> I suspect another problem with a RTF file
> produced by Crystal Report or some software like that.

I agree. It appears to be produced by Oracle Reports:

$ head -n 12 Example\ 16.rtf | grep info
{\info {\creatim \yr2012 \mo\Aug \dy02 \hr13 \min21 \sec50} {\author Oracle Reports} {\title 8354-1OZFS5A99.rtf}  }

There are 633 frames in the provided 2-page document in a layout that suggests a table is called for. While this file may be a decent stress test for frame handling I am not sure it is a RTF-specific scrolling issue, as the following indicates. I tested the provided file under Ubuntu 10.04 x86_64 running:

- v3.3.0.4 OOO330m19 Build: 6
- v3.4.6.2 OOO340m1 Build: 602
- v3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
- v3.6.7.2 Build ID: e183d5b
- v4.0.6.2 Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24
- v4.1.4.2 Build ID: 0a0440ccc0227ad9829de5f46be37cfb6edcf72

All versions really struggle with this file. Versions 3.3.0.4 and 3.4.6.2 are near unworkable, taking a long time to refresh the display. 3.5.7.2 is very slow but offers the best performance, while 3.6.7.2 is slower than 3.5.7.2, and both 4.0.6.2 and 4.1.4.2 are slower than 3.6.7.2 (but still much better than the 3.3 and 3.4 series).

Saving the provided RTF as an ODT under 3.3.0.4 shows a marked improvement in performance for subsequent handling (perhaps to something better than 3.5.7.2 levels of the original RTF). Saving the provided RTF as an ODT under 4.1.4.2 shows little or no improvement in performance for subsequent handling.

Summary amended for clarity. Version set to Inherited From OOo.
Comment 4 Jean-Baptiste Faure 2014-01-11 09:35:50 UTC
I suggest to close this bug report as NotOurBug because Oracle Report developers did a bad job (using frames instead of a true table) and it not the job of LibreOffice developers to fix that.

Best regards. JBF
Comment 5 Timon 2014-01-11 12:50:38 UTC
Sorry, but LibreOffice developers did a bad job too.
Any version of Apache Open Office from [3.4.1 m1 (Build: 9593) Rev.1372282] till [4.0.1 m5 (Build:9714) Rev.1524958] is several times faster with that particular document.
It is clear that LibreOffice and OpenOffice projects are too far apart, but some optimizations will not hurt LibreOffice.
Comment 6 retired 2014-01-12 16:34:47 UTC
Confirmed:4.3.0.0a0+:OSX

Version: 4.3.0.0.alpha0+
Build ID: cbe7ab3d6188e725414cbb15ca534f96fe51d8c7
TinderBox: MacOSX-x86@49-TDF, Branch:master, Time: 2014-01-12_00:08:19

Takes a while to open and get the spinning beachball-pizza of death on OSX. LO becomes unresponsive, CPU goes up and I force quit the madness.
Comment 7 Joel Madero 2015-05-02 15:43:52 UTC Comment hidden (obsolete)
Comment 8 Timon 2015-05-05 05:36:58 UTC
LibreOffice Version: 4.4.2.2 Build ID: c4c7d32d0d49397cad38d62472b0bc8acff48dd6 Locale: ru_RU on Windows XP SP3 Russian

Problem still present, but in that version while scrolling "CPU Use" jumps till maximum 55% on Pentium Dual-Core CPU E5300 @ 2.60 GHz with 2 Gb of RAM (only LibO is launched on computer). If we stop scrolling document, "CPU Use" drops to 0% in about 10 sec.
Comment 9 Thomas Lendo 2017-04-26 12:37:51 UTC
The example file blocked my LibO for 17 minutes until I killed the program. Couldn't open that file with my Intel Xeon CPU on Win 10 Pro, CPU load around 5-20% all the time.

Version: 5.3.2.2
Build ID: 6cd4f1ef626f15116896b1d8e1398b56da0d0ee1
CPU Threads: 8; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; Locale: de-DE (de_DE); Calc: CL
Comment 10 m_a_riosv 2017-11-03 15:11:01 UTC
Readable with:
Version: 6.0.0.0.alpha1 (x64)
Build ID: c1d1f859b268f650143d48f294999cda0fa57350
CPU threads: 4; OS: Windows 10.0; UI render: default; 
Locale: es-ES (es_ES); Calc: group

634 frames in the file (navigator).

No blocked or crash but very slow to scroll or to do anything else.
Comment 11 QA Administrators 2018-11-04 03:57:55 UTC Comment hidden (obsolete)
Comment 12 Timon 2018-11-14 09:19:21 UTC Comment hidden (obsolete)
Comment 13 QA Administrators 2019-11-15 03:35:24 UTC Comment hidden (obsolete)
Comment 14 Timon 2019-11-28 11:49:42 UTC
Version: 6.3.3.2 (x64)
Build ID: a64200df03143b798afd1ec74a12ab50359878ed
CPU Threads: 4; ОС:Windows 10.0; UI Render: GL; VCL: win; 
Locale: ru-RU (ru_RU);
Calc: threaded

Problem still present. Even file opening itself takes a long time, "Not responding" message appears, memory usage constantly around 27% on i3-8100 CPU @ 3.60 GHz with 8 Gb of RAM. LibreOffice at that time is near unworkable, taking a long time to refresh.
Comment 15 Timur 2021-04-14 12:04:13 UTC
Repro 7.2+. Another example is DOC created as RTF in Crystal Reports, attachment 78882 [details] from bug 64240.
Comment 16 Roman Kuznetsov 2021-09-21 15:02:14 UTC
Still repro in

Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 47a8a65022e3fd7624c95d0341b4809aad11fddb
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: en-US
Calc: threaded
Comment 17 QA Administrators 2023-12-06 03:18:00 UTC Comment hidden (obsolete)
Comment 18 Timon 2023-12-06 13:08:53 UTC
Still repro in

Version: 7.6.3.2 (X86_64) / LibreOffice Community
Build ID: 29d686fea9f6705b262d369fede658f824154cc0
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win
Locale: ru-RU (ru_RU); UI: ru-RU
Calc: threaded

No changes are felt. Even file opening itself takes a long time, "Not responding" message appears, memory usage constantly around 27% on i3-8100 CPU @ 3.60 GHz with 8 Gb of RAM. LibreOffice at that time is near unworkable, taking a long time to refresh.