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)
CPU utilization is around 90%
Between 5 - 15% - similar to Windows or Linux - instead of 90% would be nice for a longer battery life
User Profile Reset: No
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
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Hmm, can't reproduce this reliably with:
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%.
Is this issue still reproducible in master?
Created attachment 138762 [details]
(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..
This bug is not only affects scrolling, but it can affect everything that involving repainting anything on the page. visit: https://www.mactechnicalsupportnumbers.com/mac-customer-care-number/ to fix such bug issue son your mac.
This is really informative as I have a MacBook Air and so I found this description of CPU utilization on Mac OS really interesting and helpful. To read blogs regarding MacBook visit - https://www.mactechnicalsupportnumbers.com/blog/fix-macbook-air-wont-turn-black-screen-problem/
*** 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.
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.
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)
> 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
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 ???!!!