Description: Working on a Writer document of now 150+ pages with illustrations and stuff, even changing a word to bold makes LibreOffice to struggle during minutes. Have to edit parts of the document into separate files, then paste them into the "common trunk" when finished. But even this "simple paste" costs LibreOffice to be unavailable for more than 15+ minutes. The problem is that it also affect all LibreOffice, hence every other file opened are not responding while the Write doc is relayouting pages. Maybe sandboxing things would help a bit, and also avoid too much recursion when pages are not affected in the layout process. Can provide the file as "real world" example, yet it is private stuff. However I've seen that I'm not the only one experiencing difficulties with LibreOffice performance. My computer is quadcore with 8GB of RAM and can play OpenGL games full screen at 60FPS, so that's not the limiting factor. Steps to Reproduce: 1. Open a Writer document 2. Type something and add graphic elements 3. Continue until not being possible anymore Actual Results: Unresponsive UI, sometimes even going into infinite UI refresh loop when playing a video to wait meanwhile. The UI bar gets redrawn periodically until I stop the video to let the layout finish after minutes. Expected Results: Something that works and flows like a breeze, copy/paste between documents being instantaneous, etc. Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Can provide the file in private. Uninstalled, erased all parameters, reinstalled from scratch. Tried with or without OpenGL/OpenCL, same result. User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.) I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
Maybe bug 112568
Created attachment 142758 [details] Problematic file, real-life example This is the file I was working on, yet a lighter one since I removed about 20 pages. I edited it on a Dell Vostro 3555, AMD A8-3500M APU @ 1.5-2.4GHz with 8GB RAM, 2TB SSHD, Windows 7 Pro x64 configured for maximum performances. Go around page 88-89 and scroll up-down, observe the impossibly slow rendering with color tearing (original pictures comes from a doc file and were edited using Visio). Try editing text, adding/moving pictures. Notice on page 82, legend 'Dessin 26' is on top instead of bottom. Same on page 84 for legend 'Dessin 29'. Try moving a bit pictures on page 84, change their anchor and/or text wrapping attributes. See what happens. On page 89, not the useless void between the graphic and the legend. Had to narrow/hide the 'Dessin 38' legend to make it fit into the page. You cannot change a image/picture's size easily when it have a legend. Save and see how long it takes. Export in PDF (you have to uncheck 'General form' otherwise the resulting file is corrupted) and see how long it takes. Open the generated PDF and see how fast it is. In Draw, if you open a PDF file to import some elements into the Writer document (I converted my DOC into PDF, opened it in Draw to copy the Visio pictures), when some pages are in landscape, all the pages are loaded in landscape What happens then is that the content of portrait pages goes out of the pages. Carefully selecting several elements with a click-drag-release can be tedious procedure subject to fail if not pixel perfect aligned. Etc.
You have some complex vector drawings on 88-90. I don't experience the extreme slowness you describe, but I do have a more powerful machine (32GB RAM). Would be interesting to hear your result with a recent master: https://dev-builds.libreoffice.org/daily/master/Win-x86_64@42/current/
Yeah, thanks to have noticed the vector graphics, but those were made in 2002 on a Pentium class computer with something like 64MB memory and about 1GHz clock rate without any problem using Visio and Office of that time. I really don't think we needs a super computer with 32GB of memory to just display those vector graphics in 2018. OK it's a different engine, but these are still simple vectors. Will see is the new master is better, but keep in mind that even a PDF export of the document displays the same vector graphics without any problem. When developing, at least when testing, please use a "normal" computer to feel the "vibe" of an average user. Do you coders ever do some profiling ? I mean, like speed and/or memory consumption ? That would reveal some things.
(In reply to Kochise from comment #5) > Will see is the new master is better, but keep in mind that even a PDF > export of the document displays the same vector graphics without any > problem. When developing, at least when testing, please use a "normal" > computer to feel the "vibe" of an average user. Do you coders ever do some > profiling ? I mean, like speed and/or memory consumption ? That would reveal > some things. I am not a coder, but I do profiling.
Just tested the dev build at work on a i7-4710MQ with 20GB of memory, still slow as frozen hell.
Created attachment 143097 [details] Minimal test case I copied one of the graphics to a new document. It is slow to open even with this one graphic and retains the slightly choppy scrolling performance. I will do a callgrind profile of opening it.
Created attachment 143099 [details] Callgrind output from master Opening the minimal test case Arch Linux 64-bit Version: 6.2.0.0.alpha0+ Build ID: dbfa1c452fd9d02330cb3ec5bf2fd4f2c7782d1a CPU threads: 8; OS: Linux 4.17; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded Built on June 25th 2018
(In reply to Buovjaga from comment #9) > Created attachment 143099 [details] > Callgrind output from master > > Opening the minimal test case > > Arch Linux 64-bit > Version: 6.2.0.0.alpha0+ > Build ID: dbfa1c452fd9d02330cb3ec5bf2fd4f2c7782d1a > CPU threads: 8; OS: Linux 4.17; UI render: default; VCL: gtk3; > Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded > Built on June 25th 2018 Hrm, I have to say that the opening is slow only with gtk3. With gen backend or Windows it is not slow.
slowness under gtk3 appears to be because a massive amount of accessibility events are processed, the other platforms are presumably operating with a11y off and would suffer the same if a11y was enabled
Dear Kochise, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
LibreOffice 7.1.0.3 (x64) : seems to work (scrolling, editing) Other bugs has appeared apparently (characters are changed on load) but will open another bug for that one.
Yeah, it seems ok Arch Linux 64-bit Version: 7.1.0.3 / LibreOffice Community Build ID: 10(Build:3) CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: fi-FI (fi_FI.UTF-8); UI: en-US 7.1.0-1 Calc: threaded
Yeap, while it still strugles on some pages, it is far more bearable now. But look at page 82, Dessin 26, some accented characters (é, è) turns into the Registered character (R). Strange...