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%.

Hi Telesto,
Is this issue still reproducible in master?

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..

*** Bug 121408 has been marked as a duplicate of this bug. ***

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.

*** Bug 123283 has been marked as a duplicate of this bug. ***

*** Bug 120545 has been marked as a duplicate of this bug. ***

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.

@Tor
FWIW: the (scrolling) performance of LibreOffice on Retina screen (comment 6-10) appears to be laggy.

With version 6.2 the bug has not been fixed.

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...

(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.

@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

(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.

(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..

*** Bug 124968 has been marked as a duplicate of this bug. ***

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.

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.

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.

@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.

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.

(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.

(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.

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 !

@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 !

(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...

There has been a change lately; see bug 137468
This should prove things

A master daily including the fix is available here

https://dev-builds.libreoffice.org/daily/master/current.html

Please test & give feedback

I can confirm that the difference betweem 7.0.3 and 7.1.0_dev feels like night and day. Using Leo Wang's 1.c program for counting CoreGraphics FPS referenced in the other bug I get the following results: 

Scrolling through a blank 3-page Writer document:
7.0.3: 2-5.5 fps
7.1.0: 7-9 fps

Scrolling through a large Calc spreadsheet with hundreds of formulas and thousands of cells with values:
7.0.3: 2-4 fps
7.1.0: 9-12 fps

It is nowhere near as smooth as Office 365 yet as I get consistently between 20-35 fps scrolling through a blank 3-page Word document or scrolling through that same spreadsheet in Excel but it is definitely much more usable than before.

Hi Telesto,
is this issue fixed after https://cgit.freedesktop.org/libreoffice/core/commit/?id=87964eb39e2668f80bcbf503d9a3b55a7f86ce28 ?

*** Bug 137646 has been marked as a duplicate of this bug. ***

(In reply to Xisco Faulí from comment #32)
> Hi Telesto,
> is this issue fixed after
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=87964eb39e2668f80bcbf503d9a3b55a7f86ce28 ?

Mostly.. And prefer a new bug report anyhow; comment 31 has nice practical measure of performance.

*** This bug has been marked as a duplicate of bug 137468 ***

(In reply to Telesto from comment #24)
> 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.

Wow. I think this really **REQUIRES** an official clarification. Is LO supported on macOS or is it just a pet project, working "by luck", that could be left behind anytime ?

Some people and companies rely on it. It has to be made clear and sound.

For what's worth, I got no precise answer to my previous question (what would be the cost to get this fixed ?)

One thing I can say, sitting in my home office, is that Telesto certainly does not speak for anybody but himself. But neither do I.

(In reply to Tor Lillqvist from comment #36)
> One thing I can say, sitting in my home office, is that Telesto certainly
> does not speak for anybody but himself. But neither do I.

I should have added that in advance. I'm speaking on my personal account as volunteer. No (formal or informal) representative in any way. 

(In reply to François from comment #35)
> (In reply to Telesto from comment #24)
> > 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.
> 
> Wow. I think this really **REQUIRES** an official clarification. Is LO
> supported on macOS or is it just a pet project, working "by luck", that
> could be left behind anytime ?

And tend to slightly nuance things. Sometimes people step in to solve something. And macOS edition passed Jenskins. So developers need to take macOS into account. So not that it's really unsupported..

However macOS specific bugs kind of a thing (if you ask me). And there is Apple Silicon support! So in that sense future proof.
However macOS doesn't get the attention it ideally deserves.. Kind of niche. (Same thing for Base)

If every mac user which can already afford a mac, would take the paid (commercial) edition from a eco-system partner, this might improve things. Getting more interesting commercially with a real (paying) user base. And also a pressure to take care 

Again on my own account as volunteer. Not affiliated with the eco-system partner  - which I'm 'silently' advertising - nor speaking for TDF. The may hold another opinion. 

Topic about economics, politics, ethics, values, ideals and so on.

> Wow. I think this really **REQUIRES** an official clarification. Is LO
> supported on macOS or is it just a pet project, working "by luck", that
> could be left behind anytime ?

Is it 'supported' ? depends what you mean by support. You can get a support contract for your use of LibreOffice on Mac from the ecosystem, and then you can ask for support. One of the serious problems we have is that almost no-one bothers to purchase such support - and, as such, it is incredibly hard to fund fixing things like this.

> Some people and companies rely on it. It has to be made clear and sound.

If you are relying on something that you're not contributing to either directly yourself, or via paid support - you clearly have a problem.

> For what's worth, I got no precise answer to my previous question (what
> would be the cost to get this fixed ?)

Well, there is a significant improvement in bug#137468 which is linked, that's good - and will ship in a subsequent update I guess. Otherwise, in general fixing an arbitrary problem in LibreOffice costs from $10^3 to $10^5 with a median around $5k. Normally way beyond what any one individual can afford - which is why getting the economics of this thought through carefully is so important.

Anyhow - mercifully - due to Apple app-store sales Collabora can fix some issues as they arise, but we've been focusing on native M1 support for a while.

HTH.

@Telesto : thank you for your answer, I really appreciate it (and the tone).

My experience is still kind of weird regarding this. A few weeks ago, I've been in touch with I-don't-remember-exactly-who at Collabora.

Basically, I've been told that fixing this would cost (at least) a L3 ticket which is 14 000 €... (which gives you Office 365 for ages) and that SMBs generally can't afford it (yes, sure) and that was basically the end of the discussion :-/

I don't mind "selling" the "Collabora for SMB" ticket (17€/user/year). To be 100% honest, that's something I'm trying to do almost every day and it makes sense. But I've never been able to try "Collabora Online" nor "Collabora Office" : the provided links just don't work :-(

So, while I strongly understand that it's hard to fund things, it's also hard to sell something that works with poor performances, and where you just can't get things fixed because it costs too much :-/

Can we find a way to make everyone happy here ?

(In reply to Michael Meeks from comment #38)
> > Wow. I think this really **REQUIRES** an official clarification. Is LO
> > supported on macOS or is it just a pet project, working "by luck", that
> > could be left behind anytime ?
> 
> Is it 'supported' ? depends what you mean by support. You can get a support
> contract for your use of LibreOffice on Mac from the ecosystem, and then you
> can ask for support. One of the serious problems we have is that almost
> no-one bothers to purchase such support - and, as such, it is incredibly
> hard to fund fixing things like this.

By "supported", I meant "people are working on it, trying to make things better, fixing bugs, just like you'd do for others platforms such as Windows or Linux".


> > Some people and companies rely on it. It has to be made clear and sound.
> 
> If you are relying on something that you're not contributing to either
> directly yourself, or via paid support - you clearly have a problem.

Well, I mostly disagree with this. Supporting a free software doesn't only mean giving money. Making companies adopt it also makes it more popular and widespread. I think it also helps a lot.

Also I've never said I'm not willing to pay. I literally asked for a quote :)


> > For what's worth, I got no precise answer to my previous question (what
> > would be the cost to get this fixed ?)
> 
> Well, there is a significant improvement in bug#137468 which is linked,
> that's good - and will ship in a subsequent update I guess. Otherwise, in
> general fixing an arbitrary problem in LibreOffice costs from $10^3 to $10^5
> with a median around $5k. Normally way beyond what any one individual can
> afford - which is why getting the economics of this thought through
> carefully is so important.
> 
> Anyhow - mercifully - due to Apple app-store sales Collabora can fix some
> issues as they arise, but we've been focusing on native M1 support for a
> while.

That's good to know and fits exactly in what I meant by "supported".

Thanks for these clarifications, very much appreciated.

Hi François,

In reply to François:
> In reply to Michael Meeks from comment #38)
> > Is it 'supported' ? depends what you mean by support.
>
> By "supported", I meant "people are working on it, trying to make things
> better, fixing bugs, just like you'd do for others platforms such as
> Windows or Linux".

Surely there are people who care to fix Mac specific issues particularly, but they are very few: if Tor is working elsewhere life is bad - it is/was particularly encouraging to see Leo showing up to do good things in this ticket.

> Also I've never said I'm not willing to pay. I literally asked for a quote :)

Problem is estimation is extremely expensive; a ballpark in the handful of thousands of Euros is reasonable for most non-horrific LibreOffice bugs. Most individuals can't afford that unfortunately, so we have to aggregate donations, purchases somehow via TDF or app-stores.

>> Anyhow - mercifully - due to Apple app-store sales Collabora can fix some
>> issues as they arise, but we've been focusing on native M1 support for a
>> while.
>
> That's good to know and fits exactly in what I meant by "supported".

Of course, the speed of development is heavily limited by available resources - but there is hope that we'll improve here; bugs with lots of independent reporters are particularly interesting.

Thanks.