Extremely slow scrolling spreadsheet (tables) in 7.4.4.2 (almost hangs)

I’ve made a spreadsheet for some stocks analysis… one spreadsheet consist of 9 tab’s, mostly filled with a few thousand rows and a maximum of 142 columns (formulas in the cells, almost all columns an most spreadsheet tabs). One tab only contains diagrams, made from the data calculated in the other spreadsheets.
When I try to scroll (what in 7.3.x.x - last working is 7.3.7.2 - is working perfectly) such a table (font is Liberation Sans 10pt, so nothing fancy here) CPU begins to freak out and… the scrolling (no matter whether vertical or horizontal) almosr hangs.
7.3 didn’t have this issue.
This happens using AppImages, on a Debian Bullzeye and an AMD graphics card, an AMD Ryzen 9 5950X, 64 G RAM… so surely no outdated, “underpowered” system.

I use these spread sheets for analysis… so I don’t have the time actually to try fifferent fonts,…

BTW: I had too many hazzle/issues working with flatpak (as a consequence I banned it from my machine) and I’m not willing to use Debian’s antique 7.0.x.x of LibreOffice (which is listed under *.deb).

Is there anyone with an idea, what has changed from 7.3 to 7.4 to make this massive increase of CPU load for simple scrolling a spreadsheet?

1 Like

Scrolling problem sounds like a graphics issue. Try clicking Tools - Options - LibreOffice - View and untick Use Skia for all rendering

1 Like

Thanks for your reply… and basically I agree, but one important point speaks a clearly different language:
In both cases I use AppImages (7.3.7.2 as well as 7.4.4.2) and… before I’ve been using 7.3.6.2 and different 7.4.x.x - each time as AppImages.
Result: Each 7.3 worked smoothly and independent of the displayed content, 7.4 always (!) sucks and … the issue of sick scrolling always occured using 7.4.x.x.
Originally I even got another weirdness: Documents edited using 7.4.x opened in 7.3.x told me: Possible data loss because of too many columns (although the real column count didn’t change in the editing process). But interestingly this strangeness vanished (=obviously was a bug in the 7.4.x)… and I’m pretty sure, that a lot of bugs remain in 7.4… and these ***** want to release 7.5 :angry:

You suspect a rendering problem, but if it really is, then this must be coded in 7.4, because - as mentioned - 7.3 worked fine in all versions.

Another thing: I refuse to use the stone-old Debian-based package version of LO, which is 7.0 (!!!). And I simply don’t have time to fumble around in the OS, because I have to earn money… otherwise I would search around. Because of accessibility issues and the idiotic and completely out-of-touch-with-reality “sandboxing” of flatpak I killed it completely on my system, made it flat-free.

Sadly I should mention, that (in my memory) LO works best under flatpak, but… unfortunately that breaks other things and often led to “old” templates of documents (I edit these templates - my own ones, of course - occasionally, because they are made containing stocks analysis tools, which I overhaul from time to time, which then are updated in flatpak sandbox mostly - only, but not in the system, causing a lot of outdated processed anaysis files object of re-processing and causing a massive amount of otherwise unnecessary work and time loss.
This paranoid behavior in faltpaked apps I meanwhile see as a cheap way to avoid the meanwhile in some Linux distribution existing chaos of outdated, unresolved or otherwise not functional dependencies, but… simply making an OS minimalistic-paranoid is no way out. The only ways out in my eyes are either:

  • Re-introducing of a clean and sustainable package management with “merciless” eradication of outdated and no longer compatible packages (or - alternatively - no more updates at all in such a system… nobody can have everything )
  • Agreeing the unability to maintain open source software and giving up Linux as such a concept, making it proprietary like Unix or Windows - but at least reliable

As I understand it, an appimage is an executable that is not installed but runs entirely from it’s location like a portable app. Where does the LibreOffice user folder reside? Is it replaced with a new appimage? In which case it would depend on the person, or their computer, creating that particular appimage.

Or is it persistent, that is, is it stored outside the appimage?

The document is located - as usual - in the documents.
I found something interesting:
I use 2 monitors, but with different resolution.
Today I found, that scrolling using the display I usually don’t use, gave me a different scrolling performance. But simply pushing the open LO-document to zhe other display didn’t work (the performance didn’t change).

So as a conclusion: It has to do either with the different resolutions, with the 2-monitor-setup or in heneral with the zoom factor (because I also changed that a few times)…

I’ll try to track it down to the influencing factors…
BTW: This also happens on 7.5.0.3

No chance of trying my initial suggestion then?

[Edit]
You use 2 monitors, therefore two graphics engines. Maybe one supports Skia and the other doesn’t?
Obviously, you don’t want to take my word that it is Skia causing the problem, fair enough, I’m just some random guy. Try this link to Graphics related issues, First steps to take before submitting a bug - The Document Foundation Wiki

Funny idea, after last years mess MS created with printer-drivers. Making code proprietary does not make a single bug vanish.
.
Try the hint on skia - takes less time than reading your post…
.

I guess YOU decided to use Debian, this is the well known side-effect. But besides AppImage there is also a “TDF-install”, wich is an additional repository with a newer version, but therefore not maintained by debian as third option.

Of course I decided to use Linux - but my hope/expectation was to get rid of the well-known company-created mess (like you mentioned with drivers, … which is one example of several).
But I found out, that companies and foundations meanwhile begin to intrude and “infiltrate” the Linux world - accompanied and confirmed by the applause of many users (think on flatpak/Flathub - which is not the institution, but introduced basically by one, think on Canonical/Snap, there are many).
The “just-in-time” idea, which made the whole software world a big mess with exploding lists of bugs has entered Linux long ago - but now, that “luckily” every software package can be grabbed from a centralized software hoster (what the hell did this fact change in respect to reliablity??? Centralization limit the accessibility - that’ proven)… everythings seem to having become easier - really??? Flatpak - as an example - indeed sometimes work reliable (in some aspects more than traditional packages), but why? Because rigid restrictions in the use of the system software environment (made be possible by also rigid sandboxing) make it easier to avoid known functional critical software in many systems… but why is that still “alive” in so many systems? Basically I had the idea, that because of the open structure of Linux its creators have realized and (because of the lack of “overhead structures” made this possible), that keeping systems tidy and free of software corpses is essential. Everybody, who know even little from Windows remembers the software zombies in it for a very long time…
To point it out directly: Keeping a system healthy needs its creators to make the necessary changes plausible to the software users - such is called “customer relations” mostly - or simply: Communication with the users. The less communication the bigger the mess - and voilá, here we are!

Instead of restricting a system using not really comprehensive sandboxing techniques it would be much more straight forward to not wait for this mess of dead software residing in so many systems!
Keep the systems clean and healthy - and your packaging works without flatpak’s methods (mostly, of course). And if there’s someone who want to keep a software dinosaur alive, well… then stop adapting all the surrounding software to make it at least rudimentary work with this relict as long and safe as possible, but instead prefer to sandbox these dinosaurs instead and keep the remaining vast majority comprehensive and clean.

Flatpak as well as Canonical began to introduce the “centralized” software supply - a predecessor of the closed source concept - as everyone knows. Funny: Most of those people, who basically wanted Linux to be open, seem to have perished… and the youngsters enjoy the “well functioning” software, not understanding, that Flatpak as well as Canonical with Snap are striving straight back to the place where Microsoft began it’s “famous” way.

So again: Instead of making Linux a marketplace for more and more stone age type of software fossils it would be much more senseful to keep the systems clean and instead sandbox the museum exhibit items, keeping the whole software structure always limitless updatable, secure and comprehensive. Following the current way Linux will enter a state, where it’s basic difference from Windows will only be the logo and its inner kernel.

LibreOffice, BTW, is another prove of stupidity! Why the heck did all it’s creators first and foremost make it a Microsoft Office clone??? Instead it would have be much healthier to keep an own - hopefully powerful and also comprehensive - concept, so that the customers get convinced of it enough to prefer it to MS… But noooo, MS has to be cloned under ALL circumstances. Well, I’d claim, there’s not even one single core developer with even basic self esteem and self confidence… so it is no wonder, that it get’s more and more crappy!!!

Funny (or not): My performance issues with LO might even be caused by the OS (if I had the time I’d try to process all my documents on my Windows laptop using LO… because I’m pretty sure it worked better… again funny: I’m sure this concerns AppImage/portable version as well as installed ones - not to forget:LO basically comes from LINUX…).
But here the same idiocy: Criticism not allowed, logical thinking either.

I know, this text is messy now (bare with me), because I wrote it down as it came to my mind… and one display right and left to this one my “job” lives - so I’m not really concentrated (and not even anative English speaker…)

Hi,
.
I’m also experiencing the same issue with LO 7.5.3 (at least since 7.5.0, maybe before). I use the distro package, no flatpak/snap/appimage. I have slow scrolling on Calc but even worst on Writer.
.
I have two screen, the laptop one 1080p and an external ultra-wide one 1440p. On the laptop one, the scroll is pretty much normal whereas when moving a document on the larger screen, the scroll becomes sluggish as hell.
.
I do have have any Skia option under Tools - Options - LibreOffice - View
.
Operating System: KDE neon 5.27
KDE Plasma Version: 5.27.5
KDE Frameworks Version: 5.105.0
Qt Version: 5.15.9
Kernel Version: 6.2.14-060214-generic (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz
Memory: 15.4 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 620

You have Intel UHD 620 like me, I know this has problems with Skia. Tick the box Force Skia software rendering

IIUC, we don’t use Skia on Linux (yet).

Correct, I don’t think we have Skia on Linux. At least I don’t see any option related to Skia under Tools - Options - LibreOffice - View

Thanks, that fixed the issue for me.
My Setup:
Version: 7.5.9.2 (X86_64) / LibreOffice Community
Build ID: cdeefe45c17511d326101eed8008ac4092f278a9
CPU threads: 4; OS: Mac OS X 10.15.7; UI render: Skia/Metal; VCL: osx
Locale: de-DE (de.UTF-8); UI: en-US
Calc: threaded