Download it now!
Bug 113104 - MacOS: CPU utilization while scrolling through a plain text document is around 90% on Retina HiDPI screens
Summary: MacOS: CPU utilization while scrolling through a plain text document is aroun...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.7.2 release
Hardware: All Mac OS X (All)
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: perf
: 120545 121408 123283 124968 (view as bug list)
Depends on:
Blocks: HiDPI MacOS-Performance
  Show dependency treegraph
 
Reported: 2017-10-13 18:45 UTC by Telesto
Modified: 2020-10-18 10:30 UTC (History)
14 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot Instruments (472.97 KB, image/png)
2017-12-31 10:26 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2017-10-13 18:45:38 UTC
Description:
CPU utilization while scrolling through a document is around 90%. Should probably be around 15% or so

Steps to Reproduce:
1. Open the attachment 135838 [details] (or any random file)
2. Scroll down while monitoring CPU usage (or using Instruments time profiler)

Actual Results:  
CPU utilization is around 90%

Expected Results:
Between 5 - 15% - similar to Windows or Linux - instead of 90% would be nice for a longer battery life


Reproducible: Always

User Profile Reset: No

Additional Info:
Version: 6.0.0.0.alpha0+
Build ID: 4d94541a7b88b76d856e30dba7f8a3de48260eda
CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2017-10-08_02:51:19
Locale: nl-NL (nl_NL.UTF-8); Calc: group

and in
LibO 4.3.7.2


User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Comment 1 Alex Thurgood 2017-10-16 09:55:17 UTC
Hmm, can't reproduce this reliably with:

Version: 6.0.0.0.alpha0+
Build ID: 75539963e621faafdc0d3ef6759cadb2e0a5d9b4
CPU threads: 8; OS: Mac OS X 10.12.6; UI render: default; 
Locale: fr-FR (fr_FR.UTF-8); Calc: group


At the beginning, processeur usage does indeed climb and stay quite high on my MBPro i7 16Mb RAM, but it drops off after a while even as I scroll through the document with the arrow key and stabilizes at between 15-30%.
Comment 2 Xisco Faulí 2017-12-27 07:27:55 UTC
Hi Telesto,
Is this issue still reproducible in master?
Comment 3 Telesto 2017-12-31 10:26:39 UTC
Created attachment 138762 [details]
Screenshot Instruments

(In reply to Xisco Faulí from comment #2)
> Hi Telesto,
> Is this issue still reproducible in master?

The issue still exists with a touchpad (didn't test a mouse). Everything is working smooth, but it's CPU hogging. Only scrolling a empty writer/calc document is enough. It looks suboptimal to me..
Comment 4 shara valery 2018-09-07 07:13:39 UTC Comment hidden (spam)
Comment 5 Taylor Joe 2018-10-16 12:45:34 UTC Comment hidden (spam)
Comment 6 Alex Thurgood 2018-11-14 12:05:54 UTC
*** Bug 121408 has been marked as a duplicate of this bug. ***
Comment 7 Martin Jungowski 2018-11-28 19:55:55 UTC
All these bugs about LibreOffice user interface sluggishness under macOS are related. LibreOffice performance in macOS is horribly abysmal, and that's the nicest way I can put this without getting kicked off the internet for good.

The problem seems to lie somewhere in the way LibreOffice draws its user interface. On high-resolution Retina displays LibreOffice is so slow that you can't even scroll down an EMPTY (!!!) Writer document or an EMPTY (!!!) spreadsheet smoothly. No way, no how. Scrolling is so jumpy and laggy. When moving objects in Draw, such as text boxes, embedded images, forms, etc. the entire UI seems to choke up and lags behind by more than 1-2 seconds. Resizing an image in a Draw document is practically impossible as it takes anywhere between 2-10 seconds for screen contents to update to reflect the new size.

Starting LibreOffice in Low Resolution improves performance noticeably but in return makes the entire application appear blurry, so that's not a solution either.

This has been going on for YEARS now. I can't tell how long for sure but definitely since the early days of LibreOffice somewhere around Version 4.x. LibreOffice under macOS is unusable on every Mac released after 2012, because that is when Apple introduced their high-resolution Retina display. It is now late 2018, we have 6-core MacBook Pros and 18-core iMac Pros and LibreOffice remains completely unusable under macOS on all of these. In fact, performance is so bad I have resorted to using Microsoft Office for editing OpenDocument files because using LibreOffice to edit a simple spreadsheet or text document feels like getting punched repeatedly in the face. With a sledgehammer. Swung by Thor. On Speed.
Comment 8 Alex Thurgood 2019-02-11 08:30:37 UTC
*** Bug 123283 has been marked as a duplicate of this bug. ***
Comment 9 Alex Thurgood 2019-02-11 08:36:17 UTC
*** Bug 120545 has been marked as a duplicate of this bug. ***
Comment 10 mitja 2019-02-25 14:15:10 UTC
I agree with the comments before.
Using LibreOffice on macOS and retina displays is terribly slow.
Consumes large amount of CPU, hardware acceleration is greyed out, etc.
It is actually not possible to do a normal work on a 5K display, even though you have a new iMac.
Please, take this "bug" seriously and put a priority on it.
I'm currently using LO 6.1.5 on iMac 5K.
Comment 11 Telesto 2019-02-25 16:13:05 UTC
@Tor
FWIW: the (scrolling) performance of LibreOffice on Retina screen (comment 6-10) appears to be laggy.
Comment 12 Fabio 2019-03-08 16:57:37 UTC
With version 6.2 the bug has not been fixed.
Comment 13 laurens 2019-04-25 08:53:56 UTC
I concur - this is a real deal-breaker for using LO in a work environment.
The experience is so bad that I am more productive when I boot into a Windows VM and use Office 365 compared to using LO natively on my Macbook Pro 2018.

I have used LO since the StarOffice 6.0 days and as a business owner I want to use  LO, but the performance has gotten terrible on modern machines.

This has nothing to do with profile settings - I have tried every combination of settings...
Comment 14 Alex Thurgood 2019-04-25 09:26:48 UTC
(In reply to Martin Jungowski from comment #7)
 
> This has been going on for YEARS now. I can't tell how long for sure but
> definitely since the early days of LibreOffice somewhere around Version 4.x.
> LibreOffice under macOS is unusable on every Mac released after 2012,
> because that is when Apple introduced their high-resolution Retina display.

I can only concur. 

FWIW, for anything Draw related, I have kept LO4162, where performance remains acceptable on my MacbookPro Retina 2013 (16Mb RAM). One shouldn't have to workaround the issues in this way though.
Comment 15 Telesto 2019-04-25 09:55:03 UTC
@Alex
The new approach/hype for performance visualization are FlameGraph's SVG's. Can be shared easily and are quite informative. See bug 118822 comment 5 - 8 some info how to create them (Linux). Same can be done on MacOS too, i guess.  Didn't dive into it, yet.. But could be helpful IMHO
Comment 16 Alex Thurgood 2019-04-25 16:58:50 UTC
(In reply to Telesto from comment #15)
> @Alex
> The new approach/hype for performance visualization are FlameGraph's SVG's.
> Can be shared easily and are quite informative. See bug 118822 comment 5 - 8
> some info how to create them (Linux). Same can be done on MacOS too, i
> guess.  Didn't dive into it, yet.. But could be helpful IMHO

Hi Telesto,

You can already get at least a text based output that gives time spent for each call by using the sampler from either Instruments, or the sampler from Tools > Activity Monitor, although I'm not sure whether they use the same underlying tool.

As perf is a Linux call tool, I'm unsure as to how that would be installed on a macOS system, unless via homebrew ? As I've found that homebrew tends to pollute the rest of my environment when I have used it in the past, I have not installed it for a while and tend to shy away from it.
Comment 17 Telesto 2019-04-25 18:10:42 UTC
(In reply to Alex Thurgood from comment #16)
> You can already get at least a text based output that gives time spent for
> each call by using the sampler from either Instruments, or the sampler from
> Tools > Activity Monitor, although I'm not sure whether they use the same
> underlying tool.

Perf isn't needed. The Flame Graph can be created from the MacOS DTrace and Instruments profile (http://www.brendangregg.com/flamegraphs.html). Haven't tested it myself, yet..
Comment 18 Alex Thurgood 2019-04-29 07:07:04 UTC
*** Bug 124968 has been marked as a duplicate of this bug. ***
Comment 19 David 2019-07-27 20:48:57 UTC
Is this big being addressed?

As already mentioned, LO (both Writer and Calc) is unusable on a Retina Mac. I tried 6.x.x so far an all have abysmal scrolling performance.

The only computer I can use LO is my mother's 2011 iMac with non-Retina display.
Comment 20 Vincent 2019-11-19 17:36:21 UTC
Important information : this bug never existed on OpenOffice. You can verify this by trying OpenOffice 4.1.7.
Sadly OpenOffice project is stalled and I switched last year to LO because of all the new functionalities.

It is strange that since LO is a fork from OO, it should share most of the user interface. Something major have been changed by LO developers when they forked and sadly they have ruined LO when used in OSX.

SOMETHING MUST BE DONE !!! Why is OpenOffice scrolling smoothly with no CPU usage and not LibreOffice ???!!!

Vince.
Comment 21 François 2020-07-30 13:57:26 UTC
Hi,

How much would it cost to get this fixed ?

I've a bunch of customers that **might** be willing to pay to be able to work comfortably with LO and macOS.
Comment 22 Telesto 2020-07-30 14:24:31 UTC
@Michael Meeks

(In reply to François from comment #21)
> Hi,
> 
> How much would it cost to get this fixed ?
> 
> I've a bunch of customers that **might** be willing to pay to be able to
> work comfortably with LO and macOS.
Comment 23 Martin Jungowski 2020-08-06 18:21:02 UTC
I can hardly believe what I am about to say, but it has become even WORSE with LibreOffice 7. How is that even possible? How did the developers manage to take something that was horribly broken in the first place, and then proceed to make it even worse?

Also, what happened to Skia support on macOS? I can't find any way to force it, the release notes make no mention of it (only Windows and Linux), and the entire UI just grinds to a screeching halt as soon as I attempt to, you know, use it.
Comment 24 Telesto 2020-08-06 18:38:25 UTC
(In reply to Martin Jungowski from comment #23)
> I can hardly believe what I am about to say, but it has become even WORSE
> with LibreOffice 7. How is that even possible? How did the developers manage
> to take something that was horribly broken in the first place, and then
> proceed to make it even worse?

Is this not a a profile corruption or so? (I'm not aware of many perf complains lately). And it does work normal on my old Macbook air with they good old Sierra. 

And about developers; MacOS edition is a kind of a side-project. Virtually no-one is working on it. It's a quasi port of the Linux/Windows edition.

> Also, what happened to Skia support on macOS? I can't find any way to force
> it, the release notes make no mention of it (only Windows and Linux), and
> the entire UI just grinds to a screeching halt as soon as I attempt to, you
> know, use it.

There is no Skia support on MacOS; yet. If it will happen is matter investment decisions.
Comment 25 Martin Jungowski 2020-08-06 19:00:25 UTC
(In reply to Telesto from comment #24)
> Is this not a a profile corruption or so? (I'm not aware of many perf
> complains lately). And it does work normal on my old Macbook air with they
> good old Sierra. 
No, it's not. We've established that many moons ago ;-)

And yes, of course it works great on an old MacBook Air because the problem only arises on high-resolution Retina displays, not on low-resolution standard displays where LibreOffice continues to run perfectly fine and smooth. Unfortunately, Apple stopped selling low-resolution low-DPI iMacs in 2013, low-resolution low-DPI MacBook Pros in 2012, and low-resolution low-DPI MacBook Airs in 2018. Their last product with a low-resolution low-DPI display, the 2017 MacBook Air, was discontinued with the introduction of the 2018 Retina MacBook Air more than two years ago.

> And about developers; MacOS edition is a kind of a side-project. Virtually
> no-one is working on it. It's a quasi port of the Linux/Windows edition.

> There is no Skia support on MacOS; yet. If it will happen is matter
> investment decisions.

I was afraid of that, thank you for confirming. This basically means that LibreOffice for macOS is dead since it's completely and utterly unusable on every Mac sold since 2018, and most Macs sold since 2012.
Comment 26 Michael Meeks 2020-08-06 20:02:01 UTC
Telesto - thanks for the profile - is there any more to the profile ? I'd love to see lower down - and also where the other 50% of the CPU goes (only half of it goes down that path).

It -looks- as if we're trying to do a synchronous screen update via some ancient code-path, when we should really do an idle refresh - outside of the event processing, so that we can skip frames if we can't keep up rather than re-rendering on each one. I suspect there is a 2x from rendering each frame twice there too.

Anyone else willing to run the instrumentation & look into the profile a bit more - much appreciated. I would suggest that DrawAfterScroll is just bogus:

source/ui/view/gridwin3.cxx:void ScGridWindow::DrawAfterScroll()
source/ui/view/gridwin3.cxx-{
source/ui/view/gridwin3.cxx-    PaintImmediately(); // always, so the behaviour with and without DrawingLayer is the same
source/ui/view/gridwin3.cxx-

Looks very dodgy to me - if you're compiling; no-op. that method, or just call Window::Invalidate() instead on Mac and see if it fixes it.

Would love to know where the other 50% is though =)

Thanks !
Comment 27 Telesto 2020-08-06 20:08:09 UTC
@Alex
Do you still have/ build LibreOffice MacOS builds symbol? For running the instrument Time profile?

(In reply to Michael Meeks from comment #26)
> Anyone else willing to run the instrumentation & look into the profile a bit
> more - much appreciated. I would suggest that DrawAfterScroll is just bogus:
> 
> source/ui/view/gridwin3.cxx:void ScGridWindow::DrawAfterScroll()
> source/ui/view/gridwin3.cxx-{
> source/ui/view/gridwin3.cxx-    PaintImmediately(); // always, so the
> behaviour with and without DrawingLayer is the same
> source/ui/view/gridwin3.cxx-
> 
> Looks very dodgy to me - if you're compiling; no-op. that method, or just
> call Window::Invalidate() instead on Mac and see if it fixes it.
> 
> Would love to know where the other 50% is though =)
> 
> Thanks !
Comment 28 Alex Thurgood 2020-08-07 07:48:53 UTC
(In reply to Telesto from comment #27)
> @Alex
> Do you still have/ build LibreOffice MacOS builds symbol? For running the
> instrument Time profile?
> 

I still build with symbols, but it is unusable on the build machine which is suffering from the usual progressive slow down through multiple Apple system updates. Simply opening any app, or even the Finder takes forever, I wouldn't even dream of starting instruments on a symbols enabled build, I could go away for a week and it would still be churning away...
Comment 29 ben.munro2000 2020-09-29 20:44:18 UTC Comment hidden (me-too)