For large presentations (I'm working on one that's 117 MB), the progress bar is no longer helpful in showing the progress of the save. In past versions (such as 4.4.x), the save operation, either the autosave or the menu choice, displayed a green progress bar that moved smoothly to the right, after which it disappeared but the toolbar remained grayed-out for several seconds. Now what I see is occasional brief flashes of green in the progress bar, but otherwise just a frozen Impress window (or a completely white window), sometimes with the "(Not Responding)" indicator. This is particularly disturbing when it happens in an autosave. There are several other recent bugs having to do with FILESAVE and progress bar, such as 98731 and 67630. My behavior is similar but somewhat different. (I have a movie, but it's too long to add as an attachment.)
We'll need a test case of a large file - you can upload to google docs, dropbox, etc... Note it'll be public but we need this in order to verify the issue. For small (or even reasonable sized...) files, we're never going to see this problem. Mark as UNCONFIRMED once you get us a link to a sample file.
Maybe a dup of bug 98731 ?
(In reply to MM from comment #2) > Maybe a dup of bug 98731 ? It may be distantly related, but it's not a duplicate. The main point of 98731, as I read it, is the amount of time AFTER THE PROGRESS BAR FINISHES before the save is actually done. I've always seen that, back many versions, and that's not my issue. What's new for me, somewhere between 4.4 and the current 5.1, is that now the progress bar itself does not show continuous progress. Instead it flashes intermittently (rarely). Mostly the Impress window is just frozen or white, sometimes indicating "Not Responding" until the save is done.
(In reply to Joel Madero from comment #1) > We'll need a test case of a large file - you can upload to google docs, > dropbox, etc... > > Note it'll be public but we need this in order to verify the issue. For > small (or even reasonable sized...) files, we're never going to see this > problem. > > Mark as UNCONFIRMED once you get us a link to a sample file. Here's a link to one of my large presentations: https://drive.google.com/open?id=0B9HusC1zbjiob3BCQU02bXNrOHc Status changed to UNCONFIRMED.
Do you have OpenGL rendering enabled? If so, suspect the intermittent progress bar to be duplicate of bug 98666 -- any cleaner visually with OpenGL disabled. And perhaps post up your opengl_device.log from your profile cache. Also, with large documents it could be manifestation of poor memory handling as the ODF archive is generated on save. Check a build of master/5.2.0alpha1+ from between 20160323 and 20160406 with ref fix for bug 93553 applied (more current builds of master are suffering with first run issue of bug 99258) =-ref-= http://cgit.freedesktop.org/libreoffice/core/commit/?id=7e2ea27e5d56f5cf767a6718a0f5edc28e24af14
(In reply to V Stuart Foote from comment #5) > Do you have OpenGL rendering enabled? If so, suspect the intermittent > progress bar to be duplicate of bug 98666 -- any cleaner visually with > OpenGL disabled. "Use OpenGL for all rendering" was checked, so I unchecked it and restarted. No apparent difference in the appearance during save: just occasional green blinks in the progress bar, plus white screens and "Not Responding."
(In reply to V Stuart Foote from comment #5) > ... And perhaps post up your opengl_device.log from your > profile cache. > > =-ref-= > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=7e2ea27e5d56f5cf767a6718a0f5edc28e24af14 For what it's worth, my opengl_device.log contains only the following: DriverVersion: 9.17.10.4101 DriverDate: 1-30-2015 DeviceID: PCI\VEN_8086&DEV_0102&SUBSYS_04ED1028&REV_09 AdapterVendorID: 0x8086 AdapterDeviceID: 0x0102 AdapterSubsysID: 0x04ed1028 DeviceKey: System\CurrentControlSet\Control\Video\{6D71DF95-893E-4B65-B0A4-F74C8452EC3E}\0000 DeviceString: Intel(R) HD Graphics
Here's a link to a movie that shows what I see when I save my large presentations: https://drive.google.com/open?id=0B9HusC1zbjioaGk0dlYybzhDU2c Again, in the previous version that I had (4.4.x, I think), the progress bar behaved as you would expect, smoothly increasing to the right with no flashing and no white screen. V5.1.2.2 is very different for me.
OK, so see the sample "GSK Safari Pantanal show.odp" without OpenGL rendering enabled there is noticeable roughness in the green progress bar on saving. this on Windows 8.1 Pro 64-bit en-US with 32GB RAM with both Version: 5.1.2.2 (x64) Build ID: d3bf12ecb743fc0d20e0be0c58ca359301eb705f CPU Threads: 8; OS Version: Windows 6.29; UI Render: default; Locale: en-US (en_US) A 32-bit build with the refactored Zip routines for packaging to ODF Version: 5.2.0.0.alpha0+ Build ID: 157469896ef56720f33676222b95e81c04ab5c72 CPU Threads: 8; OS Version: Windows 6.2; UI Render: default; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-04-06_20:10:15 Locale: en-US (en_US) However, I don't believe the drag to be the Zip routines here as total time to save the archive is about the same and both builds exhibit the ragged progress bar. Suggests the issue is in the handling the high number of images (153 JPEG of 157, and 3 PNG and 1 GIF). I copied the archive and then mogrify (Imagemagick 6.9.0-Q16) all JPEG to BMP and a second copy as PNG. Edit the context to adjust image types and then open and time the save. Windows 8.1 Pro 64-bit 5.1.2.2 (64-bit) | 5.2.0alpha1+ (32-bit) *buildIDs as above JPG 14 sec | 18 sec BMP 28 sec | 33 sec PNG 24 sec | 29 sec 4.4.1.2 (32-bit) JPG 18 sec, with a smooth progress bar representation. 4.1.5.2 (32-bit) JPG 16 sec, with a smooth progress bar representation. I'll need to rerun with 64-bit build of current master, but looks as if the issue is also not the image format with JPEGs. So, just too many images being churned through?
(In reply to V Stuart Foote from comment #9) > > So, just too many images being churned through? Well, maybe, but I've been saving presentations with this many (or more) images for years, and as your experiment pointed out, in 4.4 and earlier the progress bar was smooth. So something changed in 5.1.
Hey Michael and Marco, not specifically OpenGL rendering this time, but acting like we've introduced a screen buffering issue for 5.1 and 5.2 builds as in the OpenGL issue of https://bugs.documentfoundation.org/show_bug.cgi?id=98666#c9 --but here it is when saving a complex document--and the progress bar widget is not getting updates.
Since we have a bibisect repository for windows covering the branch where this regression was introduced, adding keyword 'bibisectRequest'. More info: https://wiki.documentfoundation.org/QA/Bibisect/Windows
For what it's worth, I have retested this with version 5.2.2.2 (Build ID: 8f96e87c890bf8fa77463cd4b640a2312823f3ad) under Windows 10 (version 10.0.10586) and it still fails. The behavior is similar to what I originally reported: instead of constantly lengthening to the right, the green progress bar (beside the words "Save Document") intermittently appears and disappears as it gets longer.
** 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
The behavior of this bug is, at least approximately, the same as in the original report. In the test that I just ran, I didn't see any instances of the completely white window, but the green progress bar sometimes disappeared for several seconds, with occasional green flashes. Version: 5.3.6.1 Build ID: 686f202eff87ef707079aeb7f485847613344eb7 CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; Locale: en-US (en_US); Calc: group
I just installed 6.0.0.3 (as part of the testing of bug 115380), and I notice that this progress bar problem seems to have gotten worse, with OpenGL at least. When I save a large presentation, I now usually see no progress bar (green bar beside "Save document") at all, or maybe a bar at about 5% that never changes. This is with OpenGL rendering enabled. When I disable OpenGL rendering, the situation is more like my original report, with the green bar appearing and disappearing as the save proceeds. But this is a contrast to comment 6 from 5.1.2.2, in which OpenGL seemed to make little difference.
I bisected it to the same commit as bug 94856 *** This bug has been marked as a duplicate of bug 94856 ***