Description: Perf: scrolling a large arabic RTL document in multipage view is slower compared to Latin LTR Steps to Reproduce: 1. Open attachment 181658 [details] 2. Go to multipage view, zoom out so at minimum 6 pages fit on screen (sidebar can be closed) 3. Scroll the document with scroll-wheel (laggy) 4. Open some big file for comparison. Like Writer Manual: https://nextcloud.documentfoundation.org/s/G3DqCoDE9bxQ2m2/download?path=%2F&files=WG73-WriterGuide.odt&downloadStartSecret=20ftbxb5z6z 5. Set it again to multi-page view; 6 pages and scroll Actual Results: Performance is slowish Expected Results: Current is not bad, but there is room for improvement Reproducible: Always User Profile Reset: No Additional Info: Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 86b2bfd34a4f07c54f03c8c8dfe48e0810834628 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
The attachment document is in Hebrew not Arabic.
So, is this an Arabic issue or an RTL issue?
I don’t know, I couldn’t see a difference in scrolling the two documents. I was looking because Kashida justification in Arabic does not seem to use the glyph cache and I was wondering if it affects performance. Since this is Hebrew, Kashida would be irrelevant.
Created attachment 181760 [details] VerySleepy Screenshot Some very basic perf trace without symbols. Appears to be in TextLayout/ GlyphCache
(In reply to Khaled Hosny from comment #1) > The attachment document is in Hebrew not Arabic. Sorry, me and non-Latin languages.. Next time I put some text snipped into a translator..
Damn it, that's the attachment I posted! It's the guide to the Israeli military prison system. I'm the editor :-P Let me ask you, though - in your LO installation, do you have a font substitution for David? And can you provide a screenshot of the second page (the first one with lots of text)? > zoom out so at minimum 6 pages fit on screen (sidebar can be closed) 6 pages _fully_ fit the view, or 6 pages intersect it? Is it important that 2 full "rows" of pages fit completely?
Created attachment 184958 [details] Perf flamegraph Took a perf trace of showing 6 pages in a row and scrolling by dragging the scrollbar. I see lots of time is spent in SwSubFont::DrawText_ Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 668f55b65849012b359d7d6b9386113facbadc57 CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded
Let's set to new as we have a trace.
I doubt this issue is Hebrew-specific, so hanging on the more general meta-bug
The fix for bug 64991 introduced an up-to-95% performance improvement handling CTL DOC files. Without that fix, scrolling in the Hebrew document feels much laggier than scrolling in the Writer manual. With the fix, they now feel about the same to me. That isn't very scientific, so I also measured using headless mode. I found that attachment 181658 [details] was indeed significantly impacted by the root cause of bug 64991: Before: real 0m7.178s user 0m4.128s sys 0m1.076s With fix: real 0m3.994s user 0m1.872s sys 0m0.153s In my opinion, this bug is now fixed. I'm therefore marking it as a duplicate of bug 64991. *** This bug has been marked as a duplicate of bug 64991 ***
(In reply to Jonathan Clark from comment #10) > In my opinion, this bug is now fixed. I'm therefore marking it as a > duplicate of bug 64991. I'm experiencing a _slowdown_ in scrolling with a very recent nightly: Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7ef1c437f30b0869a5b9fa33809bac2c6665ace3 CPU threads: 4; OS: Linux 6.12; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US Calc: CL threaded relative to, say, release 25.2.4.3 Of course it possible that I have not "isolated my variables" well enough, but otherwise - not closing this one so fast.
(In reply to Eyal Rozenberg from comment #11) > (In reply to Jonathan Clark from comment #10) > > In my opinion, this bug is now fixed. I'm therefore marking it as a > > duplicate of bug 64991. > > I'm experiencing a _slowdown_ in scrolling with a very recent nightly: > relative to, say, release 25.2.4.3 > > Of course it possible that I have not "isolated my variables" well enough, > but otherwise - not closing this one so fast. This bug tracks a performance delta between attachment 181658 [details] and equivalently-complex Latin documents. The performance difference that matters for this bug is between documents using the same LO version, not for the same document across different LO versions (which may happen for a lot of unrelated reasons). Have you confirmed this same-version slowdown is still a problem?
(In reply to Jonathan Clark from comment #12) > The performance difference that > matters for this bug is between documents using the same LO version > , not for > the same document across different LO versions (which may happen for a lot > of unrelated reasons). I think you're mistaken in two respects, although my previous comment was also off the mark regarding to what this bug is about. The opening comment states: "Scrolling a large... RTL document in multipage view is slower compared to Latin LTR ... Version: 7.5.0.0.alpha0+ Build Id: 86b2bfd34a4f07c54f03c8c8dfe48e0810834628" So, the ratio of RTL-doc to LTR-doc scrolling speed, with that version, is the baseline to measure a newer version against. How did you measure scroll speed using headless mode? Maybe I can do that too.
Compared using the closest build I could find. I would call this one as fixed.