Very large files may push things to swap. Run top and see if swap usages goes up with the large files
The machine has 24 GB of RAM, of which only about 10 % are taken up, and an 8-core Intel CPU @ 2.67 GHz, of which typically less than 10 % are used.
My largest LO Writer (.odt) file has 1,200 pages, but takes up only 1.3 MB on disk.
Swap file use is constantly at absolute zero, as it should be.
I regularly use gnome-system-monitor, but iotop also shows stable 0.00 % swap file use, even with some aggressive scrolling.
However, with such scrolling, total CPU use goes up by about 10 percentage points, which is quite a lot for such an easy task.
Thank you all for good cooperation. Bug has been marked as RESOLVED on Bugzilla.
Quote:
Tomáš Chvátal <tchvatal@suse.com> changed:
What |Removed |Added
Status|CONFIRMED |RESOLVED
Resolution|--- |DUPLICATE
— Comment #3 from Tomáš Chvátal <tchvatal@suse.com> —
We plan to update to newer version that fixes this problem in near future. I am
duping this against the internal bug we have against it too.
*** This bug has been marked as a duplicate of bug 1006201 ***
I thought I would survive with LO 5.1.5.2, using libreoffice-gtk3 as a stopgap, until the promised bugfix in the “near” future will be available.
However, I no longer feel safe with LO 5.1.5.2. Almost regularly, it crashes after some time and work on the text is lost, even after “successful” restoration. This bug seems to be more dangerous than I thought.
I have therefore downgraded to LO 5.1.3.2 and deinstalled libreoffice-gtk3. Now things look normal again, much faster scrolling and prettier menus.
Since OpenGL can not be enabled, I use hardware acceleration.
Apparently, no improvement on my machine after upgrade to Leap 42.2, LibreOffice 5.1.5.2-12.1 and nvidia-glG04 367.57-18.2.
So, officially “resolved” bug still unresolved for me. Hoping for “near” future to arrive …
What says it is resolved?
Personally I have locked my version to 5.1.3.2 in order to survive any potential updates. If there is really some official info that a future version fixes the bug, I will unlock it. So - is there such info?
Bug 1005336 was declared “resolved duplicate of bug 1006201” on Bugzilla, as I quoted in message #42.
From that, it seemed to me that they had a solution (otherwise, the problem could hardly be regarded as “resolved”) and were planning to include it in an update in the “near” future, as they wrote.
But maybe to just declare it as a duplicate of an internal bug was enough for them to call it resolved.
In any case, for us lowly users, it is obviously NOT resolved. We still have to grapple with it.
What makes it worse, if somebody having the bug upgrades to Leap 42.2 without locking LO 5.1.3.2, the upgrade will replace it with LO 5.1.5.2-12.1 without keeping 5.1.3.2, and he will lose the ability to easily go back from LO 5.1.5.2 to 5.1.3.2.
So, indeed, locking LO 5.1.3.2 recommends itself as the safest solution for the time being, with or without upgrading to Leap 42.2.
I just installed today’s new update to LibreOffice 5.2.3.3-16.1 from the standard Leap 42.2 repositories, and the problem seems to be SOLVED: No more slow scrolling with fast screen flickering, and LibreOffice menus look normal again.
Tools -> Options -> View states that OpenGL is disabled. Checkboxes for Hardware Acceleration and Anti-aliasing are marked; checkboxes for OpenGL and Force OpenGL are not marked, as I had left them.
I will still have to see whether OpenGL can be enabled, but the present state is already good enough for me to unlock LibreOffice updates. Give it a try!
I just did and YaST gave me this:
#### YaST2 conflicts list - generated 2016-11-27 16:15:07 ####
libreoffice-5.2.3.3-16.1.x86_64 requires libreoffice-l10n-en = 5.2.3.3, but this requirement cannot be provided
uninstallable providers: libreoffice-l10n-en-5.2.3.3-16.1.noarch[download.opensuse.org-oss_1]
libreoffice-l10n-en-5.2.3.3-16.1.noarch[repo-update]
] break libreoffice-5.2.3.3-16.1.x86_64 by ignoring some of its dependencies
] keep libreoffice-l10n-en-5.1.3.2-8.1.noarch
] Following actions will be done:
do not install libreoffice-5.2.3.3-16.1.x86_64
do not install libreoffice-calc-5.2.3.3-16.1.x86_64
do not install libreoffice-math-5.2.3.3-16.1.x86_64
do not install libreoffice-pyuno-5.2.3.3-16.1.x86_64
do not install libreoffice-writer-5.2.3.3-16.1.x86_64
do not install libreoffice-kde4-5.2.3.3-16.1.x86_64
do not install libreoffice-calc-extensions-5.2.3.3-16.1.x86_64
do not install libreoffice-mailmerge-5.2.3.3-16.1.x86_64
deinstallation of libreoffice-writer-5.1.3.2-8.1.x86_64
deinstallation of libreoffice-pyuno-5.1.3.2-8.1.x86_64
deinstallation of libreoffice-math-5.1.3.2-8.1.x86_64
deinstallation of libreoffice-kde4-5.1.3.2-8.1.x86_64
deinstallation of libreoffice-calc-5.1.3.2-8.1.x86_64
deinstallation of libreoffice-calc-extensions-5.1.3.2-8.1.x86_64
deinstallation of libreoffice-mailmerge-5.1.3.2-8.1.x86_64
#### YaST2 conflicts list END ###
That should not be a problem. Just install libreoffice-l10n-en; I have it installed (together with its German counterpart libeoffice-l10n-de); it’s only a language component. As an intermediary step in the YAST update configuration, you may have to “break” LibreOffice 5.3.2.2, but that sounds more dramatic than it is and will correct itself automagically.
I added the package (it was locked, so I unlocked it and set it to update) but now there are some other dependency problems:
#### YaST2 conflicts list - generated 2016-11-27 19:12:33 ####
libreoffice-calc-5.2.3.3-16.1.x86_64 requires libuno_sal.so.3()(64bit), but this requirement cannot be provided
uninstallable providers: libreoffice-5.0.2.2-1.2.x86_64[download.opensuse.org-oss]
libreoffice-5.0.4.2-4.1.x86_64[download.opensuse.org-oss_1]
libreoffice-5.1.5.2-11.1.x86_64[download.opensuse.org-oss_1]
libreoffice-5.2.3.3-16.1.x86_64[download.opensuse.org-oss_1]
libreoffice-5.0.4.2-4.1.x86_64[repo-update]
libreoffice-5.1.5.2-11.1.x86_64[repo-update]
libreoffice-5.2.3.3-16.1.x86_64[repo-update]
] Following actions will be done:
do not install libreoffice-calc-5.2.3.3-16.1.x86_64
do not install libreoffice-calc-extensions-5.2.3.3-16.1.x86_64
do not install libreoffice-kde4-5.2.3.3-16.1.x86_64
do not install libreoffice-l10n-en-5.2.3.3-16.1.noarch
do not install libreoffice-math-5.2.3.3-16.1.x86_64
do not install libreoffice-pyuno-5.2.3.3-16.1.x86_64
do not install libreoffice-writer-5.2.3.3-16.1.x86_64
do not install libreoffice-writer-extensions-5.2.3.3-16.1.x86_64
do not install libreoffice-mailmerge-5.2.3.3-16.1.x86_64
deinstallation of libreoffice-writer-5.1.3.2-8.1.x86_64
deinstallation of libreoffice-pyuno-5.1.3.2-8.1.x86_64
deinstallation of libreoffice-math-5.1.3.2-8.1.x86_64
deinstallation of libreoffice-l10n-en-5.1.3.2-8.1.noarch
deinstallation of libreoffice-kde4-5.1.3.2-8.1.x86_64
deinstallation of libreoffice-calc-5.1.3.2-8.1.x86_64
deinstallation of libreoffice-writer-extensions-5.1.3.2-8.1.x86_64
deinstallation of libreoffice-calc-extensions-5.1.3.2-8.1.x86_64
deinstallation of libreoffice-mailmerge-5.1.3.2-8.1.x86_64
] break libreoffice-calc-5.2.3.3-16.1.x86_64 by ignoring some of its dependencies
] keep libreoffice-5.1.3.2-8.1.x86_64
#### YaST2 conflicts list END ###
I prefer not to break dependencies. Any other ideas?
Come on, don’t be timid 
Just the same as with libreoffice-l10n-en. Since you still have LO 5.1.3.2 on your computer, it should be easy to return to that version if your update to LO 5.2.3.3 failed (which I do not expect). My LO calc looks also OK, just as LO writer (which is my main use of LO).
In this case (as I found in many other cases), I don’t think you actually DO break dependencies when you choose to “break” them, as long as you are still in the process of YAST configuration. You “break” them only as long as your YAST configuration of the update is not yet complete. Once you have gone through all those “breaks” in the YAST configuration of the update, the update should start and run smoothly, without any ACTUAL dependency breaks.
I am not timid, I just want to do things the right way and I don’t think breaking package dependencies is the right way. As you know the thread is about 42.1, not about 42.2 where things may be different.
I can understand your reluctance, but what you experience in the YAST update configuration (namely, that alleged “breaking” of dependencies), I have experienced many times under Leap 42.2 AND 42.1, and not only with updates of LibreOffice.
It may help if you unlock your WHOLE installation of LibreOffice in ONE step under YAST. Try filtering with Search for “libreoffice”, then use Package → All in this list → Update unconditionally. If this is accepted by YAST without “breaking” of dependencies …
That last thing worked. Thanks!
I upgraded to libreoffice Version: 5.2.3.3 Build ID: 20m0(Build:3) and the veryfast scrolling persist >:(
Maybe an upgrade to Leap 42.2 would fix it? If you upgrade, you should perhaps first lock any working LO version below 5.1.5.2-12.1, in order to be able to easily revert to it, because 5.1.5.2-12.1 will be installed with the upgrade, and if you do not lock the older version, it will be replaced.
One other (far-fetched) idea:
Leap offers various (possibly conflicting) software packets for hardware acceleration: (Nvidia) VDPAU and (Intel) VAAPI.
See here for basic info: https://en.wikipedia.org/wiki/VDPAU, https://en.wikipedia.org/wiki/Video_Acceleration_API.
Could there be some mixup of these on your machine, or just the wrong ones installed?
FYI, an upgrade to Leap 42.2 currently would bring in the same LibreOffice 5.2.3.3 Build ID: 20m0(Build:3).
Here I see no problem with it (on 42.2) and the “default” rendering, while enabling OpenGL, which disables hw acceleration, still shows laggy scrolling but at a normal speed.
Maybe it is worth checking if xf86-input-synaptics is installed: it should not be needed anymore unless with very old touchpads, if xf86-input-libinput is installed.
Yes. If he upgrades to 42.2 from the DVD.iso (which I did), LO will be updated to 5.1.5.2-12.1, while the current update from the 42.2 online repo is to LO 5.2.3.3-16.1. In any case, if he wants to keep his older version of LO, he should lock it before any upgrade.
My own problem with LO has (it seems) completely been solved by the update to LO 5.2.3.3, which I made after the upgrade to Leap 42.2.
Though I still can not enable OpenGL with the LO checkbox (it reverts to unmarked after restart, even if I unmark hardware acceleration), it does not matter to me, because I just want a fast LO, with or without OpenGL. I don’t know if OpenGL would make it even faster.
I have activated the VDPAU driver for hardware acceleration, and I see in YAST that there are various other packages having to do with VDPAU, which users might possibly combine less than optimally. VDPAU is mainly Nvidia, while VA-API comes from Intel, which might account for certain hardware differences that appeared in the course of this thread. The interaction of VDPAU and VA-API, plus various other components (like OpenGL), looks rather complicated to me. I’m no expert for that.
I do not even have a touchpad on my LO machine, and no synaptics driver is installed. But with LO on mobiles, it may be worth looking into.