Created attachment 132790 [details] screenshot of problematic document Document is too large for the upload, here's a download link: https://drive.google.com/uc?id=0B78BGwELLf4wVlRMLXlqT2RUdTA This issue is specific to this document. I usually do not have issues opening docx. Open the document. Start scrolling down. Watch CPU usage massively spike and document become extremely laggy the further down you scroll. Notice some of the pictures are overlapping Tried on both 32 and 64bit versions of LO 5.3.2.2 64bit quad core AMD.
Hi funk, Thank you for taking the time to report this issue. Unfortunately with large 2 to 5 MB jpg images, each having 3500px width, there would be CPU spikes to process these images. One issue that i noticed when opening the image is that its not repaginating correctly, that is why it says 'Page 1 of 3' in the statusbar, and this seems to be caused by the images that are set as 'no wrap' appearing floating over text, so lets try to fix this regression in this bug report.
The worst lag was caused when viewing the overlapping images so hopefully resolving that improves the situation. But shouldn't image rendering be something handled by the GPU?
Text overlapping can be seen as far back as 4.4, but it got to its current bad state in 5.3. Switching to web view and back to normal view to force the repagination shows the doc as it should be. (In reply to funk from comment #2) > The worst lag was caused when viewing the overlapping images so hopefully > resolving that improves the situation. Well its 2 large images next to each other so it would be double the process to show them. > But shouldn't image rendering be something handled by the GPU? The graphics layer changed in LibreOffice 4.2, so there are still problems that need to be addressed to get it as snappy as it used to be in 4.1.
** Please read this message in its entirety before responding ** 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 http://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
funk: the Google Drive link is dead. We now have an upload limit of 30MB, maybe it would fit.
(In reply to funk from comment #0) > Document is too large for the upload, here's a download link: > https://drive.google.com/uc?id=0B78BGwELLf4wVlRMLXlqT2RUdTA 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.)
(In reply to Buovjaga from comment #5) > funk: the Google Drive link is dead. We now have an upload limit of 30MB, > maybe it would fit. File is 31MB so it wont fit. The file can be grabbed from the link below. https://drive.google.com/file/d/1sBZuB6dahqqEIPti4ERfiiVgEF6EpupL/view?usp=sharing
Created attachment 142625 [details] Problematic document I unzipped the DOCX and compressed one of the biggest jpeg file so the whole thing is below the 30 MB limit, but the problem can still be seen. If I tried to compress them all or delete one of them (from the document.xml), the problem vanished. I examined the document in the oldest and latest commit of the Win 5.3 bibisect repo, but they both had the overlapping problem in the page with the black and white photo. Win 5.2 bibisect repo on the other hand did not show the overlapping problem in its oldest and latest commits. Hopefully someone will have better luck with a Linux bibisect repo.
Created attachment 148484 [details] tdf107391_Kharta_Valley-smaller.pdf: how it looks in Word 2010 Using Ubuntu 16.04, we reviewed the history of how LO interacts with Kharta_Valley-smaller.docx (focusing on the black and white image). -before LO 4.2, it crashed the program while loading. -in 4.2, the layout was completely wrong with many extra pages etc. -in 4.3, it looked roughly like how we see it in 5.2/5.3. The text wraps in front of the picture. -no changed noticed between 5.2 and 5.3 (as an answer to comment 8). -in 5.4, the pictures have a read error. -in 6.3 master, the text still wraps behind pictures when it shouldn't. Removing keyword bibisectRequest, regression since it seems irrelevant - text wrap has never worked well. Removing perf since comment 2 focuses this bug on text-wrap. It isn't ONLY no-wrap that isn't working right. The black and white image is set to "through/contour" wrap in Word which is translated to Page/Contour in LO, so over-all text flow isn't right regardless of specific setting. Very important is comment 3 which notes that forced re-pagination works correctly. So that suggests the general logic is fine, and this is just a layout issue triggered under certain circumstances, especially in light of comment 8 where other changes also "fix" the problem.
Created attachment 158227 [details] kv.docx: 0.5MB version with severely compressed images to avoid image processing CPU lag The text wrapping seems to be fixed with proprosed patch https://gerrit.libreoffice.org/c/core/+/89586 for bug 119748 However, the overall layout is still not good. But even in Word 2010, dragging images around causes lots of confusion. I see big empty spaces where I would expect orphan/widow text to flow in and fill the space.
(In reply to Justin L from comment #10) > The text wrapping seems to be fixed with proprosed patch > https://gerrit.libreoffice.org/c/core/+/89586 for bug 119748 This has been merged for master, so this bug report should look *better* in LibreOffice 7.0
I'm going to close this issue, since the focus of all the discussion is the wrapping which was fixed in 7.0. The performance issue is still there - heavy pauses to handle the images - but other bugs already note that kind of stuff.