Bug 99403 - FILESAVE: progress bar intermittent in showing progress of save
Summary: FILESAVE: progress bar intermittent in showing progress of save
Status: RESOLVED DUPLICATE of bug 94856
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
5.1.2.2 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, regression
Depends on:
Blocks:
 
Reported: 2016-04-19 17:34 UTC by David F Smith
Modified: 2018-05-22 17:39 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David F Smith 2016-04-19 17:34:24 UTC
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.)
Comment 1 Joel Madero 2016-04-19 17:39:13 UTC
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.
Comment 2 MM 2016-04-19 17:42:14 UTC
Maybe a dup of bug 98731 ?
Comment 3 David F Smith 2016-04-19 17:54:23 UTC
(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.
Comment 4 David F Smith 2016-04-19 18:30:11 UTC
(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.
Comment 5 V Stuart Foote 2016-04-19 18:37:17 UTC
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
Comment 6 David F Smith 2016-04-19 19:11:05 UTC
(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."
Comment 7 David F Smith 2016-04-19 19:24:25 UTC
(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
Comment 8 David F Smith 2016-04-19 19:37:44 UTC
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.
Comment 9 V Stuart Foote 2016-04-19 21:38:43 UTC
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?
Comment 10 David F Smith 2016-04-19 22:48:25 UTC
(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.
Comment 11 V Stuart Foote 2016-04-19 23:25:18 UTC
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.
Comment 12 Xisco Faulí 2016-09-13 10:23:43 UTC
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
Comment 13 David F Smith 2016-09-29 15:56:34 UTC
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.
Comment 14 QA Administrators 2017-10-23 14:07:42 UTC Comment hidden (obsolete)
Comment 15 David F Smith 2017-10-23 18:30:40 UTC
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
Comment 16 David F Smith 2018-02-02 22:53:13 UTC
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.
Comment 17 Buovjaga 2018-05-22 17:39:14 UTC
I bisected it to the same commit as bug 94856

*** This bug has been marked as a duplicate of bug 94856 ***