Bug 123181 - Scrolling document with Page Down is slow/choppy when Smooth scroll is turned on
Summary: Scrolling document with Page Down is slow/choppy when Smooth scroll is turned on
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: haveBacktrace, perf
Depends on:
Blocks: Smooth-Scroll Scrolling-Performance
  Show dependency treegraph
 
Reported: 2019-02-05 12:11 UTC by Buovjaga
Modified: 2025-09-17 17:41 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Callgrind output from master (1.29 MB, application/x-xz)
2019-02-05 12:11 UTC, Buovjaga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Buovjaga 2019-02-05 12:11:57 UTC
Created attachment 148903 [details]
Callgrind output from master

1. Open attachment 136239 [details]
2. Tools - Options - Writer - View: tick Smooth scroll
3. Scroll down the document by pressing Page Down on your keyboard

Only seen with gtk3, kde5 and win.

Arch Linux 64-bit
Version: 6.3.0.0.alpha0+
Build ID: 5408f0731b9cd8be0e1b7aa5145b825337baad84
CPU threads: 8; OS: Linux 4.20; UI render: default; VCL: gtk3; 
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
Built on 5 February 2019

Version: 6.3.0.0.alpha0+ (x64)
Build ID: 573a473275ad7c76d0cada9b7e73d4923e7a79d5
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-02-03_01:22:10
Locale: fi-FI (fi_FI); UI-Language: en-US
Calc: threaded

3.3.0
Comment 1 V Stuart Foote 2021-01-27 16:28:20 UTC
Wait, does smooth scroll even respond to PgDn/PgUp or CursorDn/CursorUp? All of which relocate the edit cursor.  Yes--but the edit cursor redraw seems to come after some amount of view scroll. That redraw/reposition seems to cause a pause in smooth scroll.

Conversely smooth scroll responds cleanly to the ScrollBar control which does not relocate the edit cursor, just the views of the canvas.
Comment 2 QA Administrators 2023-12-06 03:17:53 UTC Comment hidden (obsolete)
Comment 3 measrasy 2024-04-03 09:00:13 UTC Comment hidden (spam)
Comment 4 Tex2002ans 2025-09-14 19:54:26 UTC
This is still the case in:

Version: 25.8.1.1 (X86_64)
Build ID: 54047653041915e595ad4e45cccea684809c77b5
CPU threads: 8; OS: Windows 11 X86_64 (build 22631); UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

I got INCREDIBLY SLOW scrolling with these 2 settings ON:

- Tools > Options
- LibreOffice > View
--- ON = "Use Skia for all rendering"
--- ON = "Force Skia Software rendering"

But I DID NOT get super slow scrolling with:

- ON = "Use Skia for all rendering"
- OFF = "Force Skia Software rendering"

or:

- OFF = "Use Skia for all rendering"
- OFF = "Force Skia Software rendering"

So "Force Skia" ON is the difference for me.

- - -

STEPS TO REPRODUCE

0. In LibreOffice:

- Tools > Options
- LibreOffice Writer > View
- Make sure the "Smooth Scroll" checkbox is ON.

1. Back in the document:

- Press "Page Down" a few times.

BUG: See the page go downwards at an extremely slow crawl.

= ~7 seconds to finish 1 "Page Down".

NOTE: You could also "Page Up" or use the ARROW KEYS to navigate around too.

NOTE 2: This slowdown didn't even require the "complex ODT document" test in Comment 0. I first stumbled across this in a very simple TXT document while testing another issue.

- - -

I DID NOT get super slow scrolling with:

ABOUT #1 (my default):

- "Use Skia for all rendering" ON.
- "Force Skia Software rendering" OFF.

Version: 25.8.1.1 (X86_64)
Build ID: 54047653041915e595ad4e45cccea684809c77b5
CPU threads: 8; OS: Windows 11 X86_64 (build 22631); UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

ABOUT #2:

- "Use Skia for all rendering" OFF.
- "Force Skia Software rendering" OFF.

Version: 25.8.1.1 (X86_64)
Build ID: 54047653041915e595ad4e45cccea684809c77b5
CPU threads: 8; OS: Windows 11 X86_64 (build 22631); UI render: default; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

And here is my default/working "skia.log" info too if that somehow helps:

RenderMethod: vulkan
Vendor: 0x10de
Device: 0x2504
API: 1.4.312
Driver: 580.352.0
DeviceType: discrete
DeviceName: NVIDIA GeForce RTX 3060
Denylisted: no
Comment 5 Takenori Yasuda 2025-09-15 03:35:51 UTC
I confirmed Comment 4.

But in my case, turning on "Use Skia for all rendering" and "Smooth scroll" causes this bug. "Force Skia software rendering" produced the same result whether on or off.
It is the difference for me.


Additionally, in the LibreOffice 25.8 series, this has occurred since the 2025-08-24 nightly build.

Occurred (Nightly build on 2025-08-24)
Version: 25.8.1.0.0+ (X86_64) / LibreOffice Community
Build ID: 1e040b72222012f9a5f1e47d19aaf0c0369e08ad
CPU threads: 8; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win
Locale: ja-JP (ja_JP); UI: ja-JP
Calc: CL threaded Jumbo

Not Occurred (Nightly build on 2025-08-19)
Version: 25.8.1.0.0+ (X86_64) / LibreOffice Community
Build ID: a067cfd788121ad4042cf09acf62505caf38b66c
CPU threads: 8; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win
Locale: ja-JP (ja_JP); UI: ja-JP
Calc: CL threaded Jumbo
Comment 6 Buovjaga 2025-09-17 17:41:00 UTC
I tested now both with 6.3 and 25.8.1 and the latest master and while 6.3 is choppy (Skia was not yet a thing back then), 25.8.1 and master with Skia/Raster are fine, so this is in contradiction to comment 4 and comment 5.

Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: d48fddcd2014c1366766b3785f8b533f8cb545c7
CPU threads: 2; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded