Description: When editing a multi-page document with many comments (50+), scrolling slows to a crawl. Seeking in a document of 100+ pages with many comments becomes untenable. Steps to Reproduce: 1. Write a brief paragraph of text. I copy and paste "This is a test." Until it forms a few lines. 2. Add two comments to the paragraph. 3. Copy the paragraph onto several new lines. At this point, due to the visible comments, the document should start lagging heavily. 4. Repeat for about ten pages. At this point I get enormous slowdowns. 5. Repeat for another 90 pages. At this point it takes minutes to scroll. Actual Results: 100%+ CPU usage and lag with comments, normal CPU usage without comments. Expected Results: Relatively normal performance degrading with comments Reproducible: Always User Profile Reset: Yes Additional Info: 7.2 is free of the bug, but 24 and 25 both have it.
Please attach an example document. Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the document.
Created attachment 202152 [details] Test Document
Please see the attached document, @Buovjaga.
No issue with the sample file. Version: 24.8.7.2 (X86_64) / LibreOffice Community Build ID: e07d0a63a46349d29051da79b1fde8160bab2a89 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: es-ES Calc: CL threaded OR Version: 25.2.5.2 (X86_64) / LibreOffice Community Build ID: 03d19516eb2e1dd5d4ccd751a0d6f35f35e08022 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded OR Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7f4868348c14b305fcd75744e1e3544d0d3a5d61 CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
Created attachment 202156 [details] Example file 69 pages Scrolling is slow/ even page counter is updating slow Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7f4868348c14b305fcd75744e1e3544d0d3a5d61 CPU threads: 8; OS: macOS 14.7.4; UI render: Skia/Metal; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Hard to close the file after opening (from comment 5). Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 742dbb088b44783c3a4f0fd120b11be3a74fd483 CPU threads: 16; OS: Linux 6.14; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
(In reply to FaVoR from comment #0) > 7.2 is free of the bug, but 24 and 25 both have it. Despite this claim, I actually find the slowdown appearing in Linux 7.2 bibisect repo with commit 69c546e1e7a697217f273baa7c1729ff823efd76 weld annotation window Maybe Telesto can confirm this with `git log --all --grep=69c546e1e7a697217f273baa7c1729ff823efd76` and then check out the binary commit, test and `git checkout HEAD~1`
Well the performance is quite consistently bad for years. So say 7.2 or 7.0 don't make much of a difference, IMHO. The last somewhat OK version: Versie: 4.2.0.4 Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71 However the cause probably changed/mutated/evolved over time, so not sure if this of any relevance today ----- There is a - very - recent change which makes with worse (on file open), because page counter is running too (normally it uses stored information). So shows the proper value instantly. It doesn't need to be processed. But likely not what the report experienced. Very Sleepy Profile while page counter running vcl::Window::PopPaintHelper vcl::Window::ImplCallPaint vcl::Window::PopPaintHelper vcl::Window::ImplCallPaint vcl::Window::PopPaintHelper vcl::Window::ImplCallPaint vcl::Window::PopPaintHelper vcl::Window::ImplCallPaint vcl::Window::PopPaintHelper vcl::Window::ImplCallPaint vcl::Window::PaintImmediately PaintTransparentChildren PaintTransparentChildren sdr::overlay::OverlayBitmapEx::~OverlayBitmapEx Scheduler::CallbackTaskScheduling ------------------ Something different: scrolling when page counter finished icu_77::RuleBasedBreakIterator::operator== uprv_tzset_77 icu_77::RuleBasedBreakIterator::handleSafePrevious icu_77::RuleBasedBreakIterator::setText icu_77::RuleBasedBreakIterator::setText icu_77::RuleBasedBreakIterator::preceding com_sun_star_i18n_BreakIterator_get_implementation i18npool_TextSearch_get_implementation SwDrawTextInfo::SetSpace SfxEnumItem<enum SwLineBreakClear>::GetValue SwTextFrame::GetAdditionalFirstLineOffset SwTextFrame::GetAdditionalFirstLineOffset SwTextFrame::FormatQuick SwTextFrame::GetFormatted SwTextFrame::GetCharRect SwMacroField::~SwMacroField SwPostItField::GetTextObject SwViewShell::Reformat SwCursorShell::GetPageCnt SwView::SetVisArea SwView::SetVisArea SwView::EndScrollHdl SwView::VertScrollHdl ScrollAdaptor::DoScroll vcl::Window::GetDrawPixel vcl::Window::HandleScrollCommand SwView::HandleWheelCommands I would guess that lack of glyph cache for PostItFields being the cause bad scrolling performance; profile looks pretty similar to (https://llunak.blogspot.com/2022/04/improving-text-layout-performance.html). Glyph caching became relevant since LibreOffice 5.3. Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7f4868348c14b305fcd75744e1e3544d0d3a5d61 CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded
(In reply to Telesto from comment #8) > I would guess that lack of glyph cache for PostItFields being the cause bad > scrolling performance; profile looks pretty similar to > (https://llunak.blogspot.com/2022/04/improving-text-layout-performance.html). > Glyph caching became relevant since LibreOffice 5.3. Well maybe not glyph caching, but ICU text breaking (also mentioned in the blog post)
(In reply to Telesto from comment #8) > Well the performance is quite consistently bad for years. So say 7.2 or 7.0 > don't make much of a difference, IMHO. The last somewhat OK version: > Versie: 4.2.0.4 > Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71 There *is* a clear difference in 7.2 with the commit I mentioned. Yes, scrolling is choppy before, but after the commit the repaint lag maybe quadruples.
(In reply to Buovjaga from comment #10) > There *is* a clear difference in 7.2 with the commit I mentioned. Yes, > scrolling is choppy before, but after the commit the repaint lag maybe > quadruples. Well sounds Linux specific. Probably backend specific. Master scrolls slightly smoother for me.
(In reply to Telesto from comment #11) > (In reply to Buovjaga from comment #10) > > There *is* a clear difference in 7.2 with the commit I mentioned. Yes, > > scrolling is choppy before, but after the commit the repaint lag maybe > > quadruples. > > Well sounds Linux specific. Probably backend specific. Master scrolls > slightly smoother for me. It may sound like it, but it isn't. For testing, I was using a document expanded to 101 pages from attachment 202152 [details]. I now tested with Windows 7.2 repo and with the commit, the application freezes and I am unable to do anything, even after waiting a few minutes. With the preceding commit, I am able to scroll with some choppiness. Windows master from 8 July doesn't freeze like that, but scrolls like 10 times slower than the "good" state in 7.2.
(In reply to Buovjaga from comment #12) > Windows master from 8 July doesn't freeze like that, but scrolls like 10 > times slower than the "good" state in 7.2. I'm unable to explain why, but I'm not noticing any additional performance hit Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 2c61782812b1b8b382dd48a04a712da9eaeb4685 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL performance is similar to (sorry, no recent daily's available). The scroll performance is even better as long as the page counter is counting, especially at with page counter at 20-30; apparently it's still adding PostIt's) Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7f4868348c14b305fcd75744e1e3544d0d3a5d61 CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded ----- Yes, there is massive performance between `git log --all --grep=69c546e1e7a697217f273baa7c1729ff823efd76` and then check out the binary commit, test and `git checkout HEAD~1` However the additional performance lag disappeared again; at least for me
Created attachment 202184 [details] Perf flamegraph of scrolling Tried (and largely failed) to scroll in attachment 202156 [details] for some seconds by clicking and dragging the scrollbar. Arch Linux 64-bit Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 83ccb2bba3fdbdd0b0ec3c2ca6609b5a11c36aee CPU threads: 8; OS: Linux 6.15; UI render: default; VCL: gtk3 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded Built on 5 August 2025
A lot of gtk_container_propogate_draw so its not entirely clear what is going in there. Perhaps we are triggering too much redraw, or not limiting to on screen widgets
FWIW, the page counter being updated incrementally instead of opening with 69 pages started with $ git bisect bad c36ac74ea0ebd5fe4460e4cccf6b2ea38ea11550 is the first bad commit commit c36ac74ea0ebd5fe4460e4cccf6b2ea38ea11550 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Sat Jun 7 03:16:02 2025 -0700 source b6bcc7ac278e0db22df02707789730ec123bf934 source b6bcc7ac278e0db22df02707789730ec123bf934 Saving with master, and reopening -> No change, page counters starts again
(In reply to Telesto from comment #16) > FWIW, the page counter being updated incrementally instead of opening with > 69 pages started with > > $ git bisect bad c36ac74ea0ebd5fe4460e4cccf6b2ea38ea11550 is the first bad > commit > commit c36ac74ea0ebd5fe4460e4cccf6b2ea38ea11550 > Author: Norbert Thiebaud <nthiebaud@gmail.com> > Date: Sat Jun 7 03:16:02 2025 -0700 > > source b6bcc7ac278e0db22df02707789730ec123bf934 > > source b6bcc7ac278e0db22df02707789730ec123bf934 > > Saving with master, and reopening -> No change, page counters starts again Reading the commit message, this is a feature and not a bug.
https://gerrit.libreoffice.org/c/core/+/189139
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e246d070d7ee3859df0090077e1071e897c453b5 tdf#167775 writer doc with lots of comments slow It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Still slow for me Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ccb3362a71f88213615bd39bd819ab8ec20d86cc CPU threads: 8; OS: macOS 14.7.4; UI render: Skia/Metal; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded It's fast on file open. Slow again when the page counter finishes
@Buovjaga Does the patch bring any improvement at your side?
(In reply to Telesto from comment #21) > @Buovjaga > Does the patch bring any improvement at your side? In the patch I commented: Looks like a no-brainer and an easy win! On Linux, the effect is clearly seen when using the gen backend. Gtk3 seems to suffer from some additional slowness, which makes it harder to quantify just by UI interaction, but there is still some improvement. Qt UIs under Wayland have a general scrolling slowness issue of unknown origin (tdf#152911), so they can't be used to test.