Description: In a long document (100,000 words), I execute a Find in the Find and Replace dialogue. Find Next works OK but when I select Find All scrolling becomes very slow. For testing I kept the query as simple as possible. The slowness occurs when there are many hits, even if there are no hits on the current/next page. It's not a problem with 10 hits but a big problem with 1500 hits. Steps to Reproduce: 1. Prepare a long document in Writer (eg over 100,000 words) 2. Open Find and Replace 3. Look for a string 4. Select Find All 5. Scroll page Actual Results: Slow scrolling. Expected Results: Fast scrolling as usual. Reproducible: Always User Profile Reset: No Additional Info: This happens with many hits (eg 1500) but not with few hits (eg 10).
Can confirm. Downloaded WG252-WriterGuide.odt from https://documentation.libreoffice.org/en/english-documentation/ and searched "to" with Find all After some time, the UI becomes as responsive as before, meaning a background process lags the UI for some time. Tested with : Version: 7.2.0.1 / LibreOffice Community Build ID: 32efc3b7f3a71cfa6a7fa3f6c208333df48656cc CPU threads: 8; OS: Linux 6.11; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f355ddcbf2bf037263e336724829b5467b94ef40 CPU threads: 8; OS: Linux 6.11; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: CL threaded
Created attachment 200434 [details] Sample 1. Open the attached file 2. Search for 'Draw' 3. Scroll through the document in single page or multipage view Found in Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: feb3c03b70ac1534a187e390c3bc1604a919ce12 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 and in Versie: 4.4.7.2 Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Locale: nl_NL and in LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 The highlighting flashes while scrolling in older versions. It appears - to me; without any clue of the internal works - as if the highlighting is painted over the matching text on the fly. It might even be that each and every hit on the same page being painted on by be one. So first line of text hit. Paint highlighting. Next line, again hit. Paint the same page again with highlighting on first and second line. So quite expensive exercise. So instead of finding all matching items on a single page, and painting once, it's done for each hit separately. And the result might not be being buffered/cached either. So scrolling over a page which you scrolled through before, triggers the whole find word and paint highlighting stuff over and over. So it's not slow once, but faster after. FWIW: This is - in my perception - the same issue which occurs with comments. The comment highlighting is also rendering slowly and in a similar fashion as seen here.