Problem description: The memory configuration of 256 MB for LibreOffice does not produce the expected result. Steps to reproduce: 1. Tools - Options - Memory - Use for LibreOffice - 256 MB - OK 2. Scroll Big document UP or DOWN 3. Notice that writer freezes at each beginning or end of page Current behavior: Expected behavior: The scrolling used to be relatively smooth with earlier release (4.1.3.2), even with big documents (mine is over 7 MB). Another point is that we should be able to allocate MORE than 256 MB for LibreOffice. Operating System: Windows 7 Version: 4.1.4.2 release Last worked in: 4.1.3.2 release
Created attachment 91492 [details] Memory Configuration
take a look at Bug 63433 from your description it seems to me that you are describing the same issue. feel free to reopen the current bug if you think it's a different problem *** This bug has been marked as a duplicate of bug 63433 ***
My proposal is to let people allocate to LibreOffice as much memory (above 256 MB) as they need, considering their document size and the number of pictures inserted in it.
Ok you reopened it, but please explain why you think this is different from Bug 63433. moreover it would be useful to have a copy of your document to test. it's too large to be attached here but you could upload to any webhosting site and drop here the link. regarding the memory allocation proposal you can open a separate report for this enhancement request.
I agree with comment #4 that this bug is about scrolling performance and not the particular memory setting indicated. There are several other bugs relating to scroll+slow: https://bugs.freedesktop.org/buglist.cgi?query_format=advanced&list_id=381597&short_desc=scroll%20slow&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=PLEASETEST&short_desc_type=allwordssubstr&product=LibreOffice ... with most recent reports being UNCONFIRMED or NEEDINFO. The reporter needs to demonstrate how this report differs from earlier reports. > regarding the memory allocation proposal you can open a separate report for this enhancement request. Bug 45302 was raised (and closed due to inactivity) for this exact issue e.g., raising the limit of the "Use for LibreOffice" field above 256MB. Overall however bug 47148 may be the reason for this particular limitation.
Sorry for the delay; I'm doing this on my free time. 1) You receive numerous reports about this slow scrolling issue and you somehow manage to close them! Isn't there a problem here? 2) My memory enhancement proposal might be related to this issue: suppose that you have more than 256 x 1MB images (or a high number of images so that the total amount of memory necessary to store/handle them exceeds 256 MB) inside a particular document, how would this situation be handled by the code? 3) "Bug 45302 was raised (and closed due to inactivity) for this exact issue e.g., raising the limit of the "Use for LibreOffice" field above 256MB. Overall however bug 47148 may be the reason for this particular limitation." As far as I understood, the bug 47148 was issued with some much earlier LibreOffice releases. Requesting more than 256 MB for the images should be possible or something should be corrected inside the code. 4) I can hand over the big document as I have already done in the past with other issues. However, this should be tested within the same environment (Windows 7, English version of LO 4.1.4.2), otherwise the results might be different. Everything works fine at the beginning; things get slower and slower when you begin to edit it, save it, close it, edit it, save it, close it and so on for a few days. That makes me think there might be an issue with memory management: is all memory correctly released when the file is saved and closed?
The big file can be accessed here: http://ubuntuone.com/73qxpooo51291kfWdoCf3Z
(In reply to comment #7) > The big file can be accessed here: > http://ubuntuone.com/73qxpooo51291kfWdoCf3Z tested under Win7 64bit slow scrolling confirmed in LibO 4.1.4.2 scrolling is fine with LibO 4.2.1.0.0+ this means that the fix for Bug 63433 has effects on your test file too. this implies that your report was a DUPLICATE as I labeled it in Comment 2. so I'm closing again this report since it's finally fixed. the fix will be available in LibO 4.2.0 which will be released in end of january / early february, so you won't have to wait too much. *** This bug has been marked as a duplicate of bug 63433 ***
(In reply to comment #6) > Sorry for the delay; I'm doing this on my free time. > > 1) You receive numerous reports about this slow scrolling issue and you > somehow manage to close them! Isn't there a problem here? we don't CLOSE problems, we just CLOSE duplicates. the policy of the bug tracker is to keep open just one single report for the same issue. that's what happened... as a QA member I've noticed that your issue was pretty the same of Bug 63433 and I marked it as a duplicate. see Comment 2 > 2) My memory enhancement proposal might be related to this issue: suppose > that you have more than 256 x 1MB images (or a high number of images so that > the total amount of memory necessary to store/handle them exceeds 256 MB) > inside a particular document, how would this situation be handled by the > code? as already said before (see Comment 4) you should open a new clean report with this enhancement proposal. > 3) "Bug 45302 was raised (and closed due to inactivity) for this exact issue > e.g., raising the limit of the "Use for LibreOffice" field above 256MB. Bug 45302 was closed due to lack of feedback from reporter. when we mark an issue with NEEDINFO and do not receive a reply in 6 months we mark this as INVALID > Overall however bug 47148 may be the reason for this particular limitation." > As far as I understood, the bug 47148 was issued with some much earlier > LibreOffice releases. > Requesting more than 256 MB for the images should be possible or something > should be corrected inside the code. I don't know. only a developer may answer to this. > 4) I can hand over the big document as I have already done in the past with > other issues. However, this should be tested within the same environment > (Windows 7, English version of LO 4.1.4.2), otherwise the results might be > different. did that, see comment 8. next time immediately upload a test document. It makes debugging easier and faster. > Everything works fine at the beginning; things get slower and slower when > you begin to edit it, save it, close it, edit it, save it, close it and so > on for a few days. > That makes me think there might be an issue with memory management: is all > memory correctly released when the file is saved and closed? I don't know what exactly has been fixed in Bug 63433... but I can tell you that has nothing to do with memory allocation since in the 4.2.x menu you still cannot raise to limit above 256MB.
@actionmystique You test case is no longer available for download. Please confirm that LibO 4.2.1.0.0+ fixes your issue. For your feature enhancement, please file a new bug report if you haven't already done so.
The bug is still there with 4.2.0 which is the last stable release.
Marking it as "Resolved" won't solve it.
@actionmystique your report was marked a s a DUPLICATE of 63433 which is FIXED If you believe this is a different issue and still persists in current LibO releases, despite the fix of Bug 6433, please provide a test file and reopen this report. without any test file it will impossible to verify your bug
@actionmystique Your test case is no longer available for download. Please reupload it to someplace that is less ephemeral such as: https://www.dropbox.com/ https://drive.google.com/ https://mega.co.nz/ There is no way we can help you if we can't verify the problem ourselves.
Here's a link to a big file with many pictures which can cause very slow scrolling after some time: http://ubuntuone.com/1Wwy6lRns1YiHY90x5Oz2f Be careful to use the same environment as mine (last stable LO release, Windows 7/8).
not reproducible with LibO 4.1.5.3 under Win7 64bit. scrolling is smooth with arrowkeys, mouse wheel and even moving the scrollbar with left mouse button pressed. even "mad scrolling" causes no freeze. I'm also working with just 20 MB of memory so it WORKSFORME. @actionmystique the FIX for Bug 63433 which is considered a duplicate of your report is available from 4.1.5 and should be present in 4.2.0 as well
the freeze issue you describe is present (and I can reproduce it on my PC) with 4.1.4 but as said before is gone in 4.1.5 after the above mentioned fix.
Right now, I'm using 4.2.0.4 under Windows 8.1. You need to wait sometime (like at least 15 mn) without any action on the document (no scrolling, no typing) and the freezing happens.
@actionmystique I also have a Win 8.1 box to test on. Unfortunately, every attempt to download your test case has failed. Always the same error. "Could not locate object" If you can't upload the file to someplace where the QA team can access it, there is nothing we can do to help you.
I will soon provide a video since my words are not enough. By the way, you're not helping only me. This bug affects all people editing large files containing many pictures. Do you really think I would spend this time reporting this issue if I hadn't experienced it?
@actionmystique I never asked you for more pictures, words, or videos. What we need is a reliable place to download your test case. Here is a list of free cloud storage lockers that can handle large files: https://www.dropbox.com/ https://drive.google.com/ https://mega.co.nz/ https://onedrive.live.com/ There is no way we can help you, if we can't verify the problem ourselves.
The following video shows the ***unsolved bug*** related to screen freeze (Windows 8.1 - LO 4.2). I performed the following tasks: 1) Inserted a page long text in the middle of a (long) LO document containing many pictures (not sure if the high number of pictures is related to this bug or not); also there's a page break just before "4. Data Center Design", maybe this plays a role too in the bug. 2) Waited a while before any scrolling or any other action 3) Scrolled up when the video shows 00:18 - LO freezes until 00:26 and then LO jumps approximately one page up at 00:27 Now, it's up to you to report this bug to the developers or bury your head(s) in the sand. No offense.
The video is available here: https://drive.google.com/file/d/0B5fXyIn0-GDFSjFlTm9pQUhzQmM/edit?usp=sharing Let me know if you experience any problem with the streaming.
there's no video and no link. what should we do?
nevermind. midair collision. now I see the link
I forgot to mention that this was done on a powerful laptop: i7 4700 MQ, 16 GB of RAM and a fast HD with plenty of space.
did you try disabling the right panel (is that index?) and see if you still see the scrolling issue? morover it would be important to have a test file consistently accessible... the links where you posted it before are expired. P.S. please change attitude, some of your comments sound too harsh and aggressive.
Please see comment #21. There is no way for us to reproduce this bug without a test file.
It's been 4 months and actionmystique has still not provided the information that we requested. This bug should remain closed until actionmystique answers tommy27's questions AND provides a stable location to download problematic file.
I've just done some tests with the same files, but with LO 4.2.5.2: 1) the issue described on this thread has been resolved; 2) however, there's another issue related to graphics in large documents: some blank pages are randomly inserted before the pictures, but that's another story. I'll post another thread when I find the time. The same comments can be applied with LO 4.2.4.2 on Ubuntu 14.04. HTH. Regards. N.B: please do not mark bug reports as "Resolved - Invalid" when you are unable to confirm or deny them for whatever reason: different environment, ... Everyone is doing his/her best, ther's no reason to denigrate other people's work. I would not take all that time to help you out if I hadn't experienced them for real.
@actionmystique > please do not mark bug reports as "Resolved - Invalid" when you are unable to confirm or deny them for whatever reason: different environment, ... This report was marked Invalid because it was impossible to reproduce without a test file. Our requests for one has been ignored for over 4 months. In addition, tommy’s questions were ignored.
I provided the test files in the past for other bug reports; I'm done with that for 2 main reasons: 1) people used them in different environments than mine, and jumped into (false) conclusions; 2) I've been working recently on documents which cannot be disclosed Videos & text are the best I can provide; I never use special weird configuration or files, so it should be pretty easy for guys checking on other people's reports to have predefined small, medium and big files.
@actionmystique > I provided the test files in the past for other bug reports; I'm done with that for 2 main reasons: 1) people used them in different environments than mine, and jumped into (false) conclusions; The QA team is composed of volunteers doing their best to help within the limits of their working environment. People make mistakes, but they are trying to help you and to make a LO a better product. If you're unwilling to provide information because of a fear that we will get different results, then there is no way for us to help you. A test file is often necessary to reproduce results. Please read following article as it might help you understand where we are coming from: http://www.chiark.greenend.org.uk/~sgtatham/bugs.html > 2) I've been working recently on documents which cannot be disclosed I had a similar issue with files from my job, so I replaced all of the text with a Lorem Ipsum generator.
Migrating Whiteboard tags to Keywords: (possibleRegression) [NinjaEdit]