Description: When comments are shown on screen scrolling slows down very strong / scrolling is stuttering. Steps to Reproduce: 1. Write a text about 5 to 6 pages long. 2. Add two comments on page 2. (And set "show comments") 3. Click (and hold) on the scrollbar and scroll around page 4 to 6. 3b. This should be rather smooth. 4. Scroll around 1,2 and 3. Actual Results: 4b. Actual: Scrolling slows down / starts to "stutter" as soon as comments are on screen. Expected Results: 4b. Expected: Scrolling should be as smooth as without comments. Reproducible: Always User Profile Reset: Yes Additional Info: Happens with OpenGL enabled and disabled. Tested machine: Core i5 8th Gen, 12GB RAM.
I think, we can treet thsi as a duplicate of bug 61558. Do you agree?
> I think, we can treat this as a duplicate of bug 61558. > Do you agree? No, I would not say so. It seems related, though. Bug 61558 has a lot of unclear discussion going on. But deciding from the attached file: With or without comments, I have problems even opening the document. The whole navigation is very laggy. So I'd say: the cause MIGHT be the same as 61558, but the symptoms are slightly different. This is about my bug here: ---------------------------- While scrolling without comments on the screen I have no problem. While scrolling with comments on the screen I have: (program "top" output:) - I have 50 to 55% CPU usage for soffice.bin . - I have 45 to 50% CPU usage for Xorg . (program "gnome-system-monitor output) - I have 5% CPU usage for soffice.bin . Memory is not constantly increasing. Comparison to bug 61558: - Memory usage keeps increasing ( here: I can't see increasing memory in my bug. ) - Scrolling in general causes problems ( here: I only have problems, if comments are shown. )
Created attachment 152118 [details] Example file with 2 comments. Scrolling around an area without comments works fine. Scrolling in an area where comments need to be rendered, scrolling is very laggy.
this not happen in stable version: Version: 6.3.3.2.0+ Build ID: 6.3.3.2-2.fc31 CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded Also in master: Version: 6.4.0.0.alpha1+ Build ID: 47ce1d70a287c2e652603ba6810a6bb6745338bf CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-11-06_11:54:25 Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
(In reply to BottleOnTheGround from comment #3) > Created attachment 152118 [details] > Example file with 2 comments. > > Scrolling around an area without comments works fine. > Scrolling in an area where comments need to be rendered, scrolling is very > laggy. With regard to comment 4: Doe you use the latest version of LO'. If not, could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ or with with a master build from http://dev-builds.libreoffice.org/daily/master/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version. Change to RESOLVED WORKSFORME, if the problem went away.
I would try, but running 6.5.0.0 tells me I need to install GLIBC_2.29: ./swriter/[...]/program/oosplash: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by [...]/program/oosplash) If I know how I can install that, I can try.
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to BottleOnTheGround from comment #6) > I would try, but running 6.5.0.0 tells me I need to install GLIBC_2.29: I assume there is no big difference between 6.5.0.0 and 6.4.0.0beata1 (will also be installed in paralel). Perhaps you can give it a try. You can download it from pre-releases: https://dev-builds.libreoffice.org/pre-releases/
Confirm bug with 6.4.0.0beata1 Is not fixed.
Hello BottleOntheGround, Could you please paste the info from Help - about LibreOffice ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the information has been provided
Version: 6.4.0.0.alpha1 Build ID: cc57df8f942f239d29cb575ea5a7cb01405db787 CPU threads: 1; OS: Linux 4.18; UI render: default; VCL: gtk3; Locale: en-US (en_US); UI-Language: en-US Calc: threaded
No repro with example Arch Linux 64-bit Version: 7.0.0.0.alpha1+ Build ID: e622420c0aa8116294e85c076ff2d8fc6131595f CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: gtk3; Locale: en-US (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 10 May 2020
(In reply to DarkTrick from comment #11) > Version: 6.4.0.0.alpha1 > Build ID: cc57df8f942f239d29cb575ea5a7cb01405db787 > CPU threads: 1; OS: Linux 4.18; UI render: default; VCL: gtk3; > Locale: en-US (en_US); UI-Language: en-US > Calc: threaded Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Version: 7.0.0.0.beta2 Build ID: 1c213561a365b5666167321de68c9977500c9612 CPU threads: 2; OS: Linux 5.3; UI render: default; VCL: gtk3 Locale: en-US (en_US); UI: en-US Calc: threaded No repo (awesome!)
(In reply to DarkTrick from comment #14) > Version: 7.0.0.0.beta2 > Build ID: 1c213561a365b5666167321de68c9977500c9612 > CPU threads: 2; OS: Linux 5.3; UI render: default; VCL: gtk3 > Locale: en-US (en_US); UI: en-US > Calc: threaded > > No repo (awesome!) Then this goes to worksforme. Btw. jargon correctness: repo = repository, repro = reproduce/reproduction :P