Issue 125490

Embed some huge large pictures may slow down or corrupt your file.
We still debate here: https://issues.apache.org/ooo/show_bug.cgi?id=15379

1  This bug report is because AOO 4.1.1 is slower with large images than 4.0.1, and crashes when zoomed out.  https://issues.apache.org/ooo/show_bug.cgi?id=15379 is asking that large pixel count images which are inserted at small dimensions, are re-sampled to smaller pixel count, to keep the file size small.  

2  I quote "Embed some huge large pictures may slow down or corrupt your file".  Adding images should NEVER the file.  It is a serious bug if adding images corrupts the file.  Images are filed in a separate folder in the odt file, and merely called up and displayed at the user requested size on the page.  That should be independent of the number and size of the images.

Oops.  "Adding images should NEVER the file..." should read "Adding images should NEVER corrupt the file..."

I was able to replicate the failure (Writer hangs) by following the steps to reproduce the bug on my system: Windows 7 Ultimate, 64 bit operating system, processor Intel(R) Core (TM) i5-3317U CPU @ 1.70 GHz). 

After step 5 (Steps to reproduce posted by John) the Open Office (v 4.1.1) became unresponsive. The average CPU used by Open Office was 25%. 

By performing some follow-up tests I can add that although the program becomes unresponsive, the user can retrieve the file. The pictures mentioned in the description do not have to be inserted in a table. The failure seems to occur only if the (Place large photos to add a large size ~130 MB in a new Writer document, set layout to 2 page view and zoom out) sequence is performed. 

Some other follow-up tests and their results: 

1. Reproduce the failure by following the steps posted in the report on version 4.2.0 of Open Office. 
Result: The failure is reproducible also on the 4.2.0 version. 

2. Reproduce the failure without the 30 rows table
Steps:
     1. Add 26 x ~5MB .jpeg photos in a New A4 document.
     2. Set the layout to a 2-page view.
     3. Zoom out to 25%.

Result: The Writer becomes unresponsive. 

3. Reproduce the failure by using an already created document that has the photos saved in a table.
Steps: 
    1. Create a new A4 document.(Automatic layout)
    2. Add a 30 line table.
    3. Add 26 x 5MB .jpeg photos in the table.
    4. Save the document.  
    5. Open the previously created document and set the layout to 2 page view.
    6. Zoom out to 25%
Result: The Viewer did not become unresponsive.

4. Retrieve the file lost by the hanging of the program.
Steps: 
    1.Reproduce the failure. (Steps provided by John)
    2.Choose to close the program after the program hangs.
    3.Open the program and retrieve the file
Result: The file can be retrieved.

Machine used: MacBook Pro (Retina, 15-inch, Mid 2015), 16GB, 2.8 GHz Intel Core i7
OO versions:
AOO411m6(Build:9775)  -  Rev. 1617669 2014-08-13 09:05:42 (Wed, 13 Aug 2014)
AOO413m1(Build:9783)  -  Rev. 1761381 2016-09-23 02:39:34 (Fri, 23 Sep 2016)

4.2.0 build was not available for macOS so I’ve tried 4.1.3 and 4.1.1 later. Tested using steps provided in original description. In the end, only slow scroll was reproducible (and only until images were loaded to memory). 2-page layout + zoom out caused few seconds of loading after which writer was usable again - so it did not hang like originally reported. Also, unlike in the original report, my machine used 100% of cpu.

Could you try new 4.1.5-dev build?
http://home.apache.org/~jim/AOO-builds/AOO-4.1.5-dev-20171120/

(In reply to oooforum (fr) from comment #6)
> Could you try new 4.1.5-dev build?
> http://home.apache.org/~jim/AOO-builds/AOO-4.1.5-dev-20171120/

I am the original poster.  I do not have my original test file so I created a new test.odt with 43 x JPG images 3,888 x 2,592 pixels, where each JPG was 2.5 to 4MB.  The total size of \Pictures in the .odt was 141MB.

1 Using 4.1.4 the file was very difficult to manage and AOO stopped responding  when I scrolled.  AOO may have recovered had I left it much longer.  TaskManager showed AOO was using 50% of my dual CPU but, when I showed both CPUs, both were active and about equal (so unlikely to be a single thread in just one core).

2  I installed http://home.apache.org/~jim/AOO-builds/AOO-4.1.5-dev-20171120/ as a vanilla install with a default new user profile - I had previoulsy renamed my profile to ensure it was not used.

3  I opened test.odt and AOO was very slow.  When I went to two-page display it stopped responding for many seconds.

4  I wanted to obscure faces before posting the test.odt file so, starting at the front of the file, I copied an image in the file (r-click > Copy), pasted it into an image editor, obscured the faces, saved as JPG, and dragged the JPG file back to AOO on top of the highlighted image to replace it.  

After having pasted image 14, all the previous 13 images disappeared and I got  empty frames with an error message - it was Read Error? or Frame error? - I cannot recall.  Scrolling was very slow and showed multiple overwritten error messages per page.  I saved the file as Test 2 and on opening, Navigator showed images 1 - 13 were no longer present.

5  I continued with test 2.odt obscuring faces and when I got to image 35? 36?, I lost all the previous images again.  I saved it as test 3.odt and Navigator showed images up to 35 were now missing missing.

6  I re-created test.odt with 43 images now with obscured faces - it was now 157 MB.  AOO was full screen and it opened one page wide, and it took me 45 seconds to scroll (mouse wheel) from start to end, and 45 seconds to scroll back.

7  The document was initially full screen, one page wide.  I now set it to multiple pages - not book.  I pressed ( - ) repeatedly and AOO went to 2 pages wide.  Continuing, when I get to 79%, AOO went to 3 pages wide and the PC became unresponsive for many (30? 45?) seconds with grossly corrupted screen image (Notepad session chopped up with bits in front of AOO, and AOO in front of bits of Notepad), and some AOO images wee overlaying themselves and/or chopped up horizontally.  Notepad was non-responsive (but see 9 - is it because I attempted to minimise it?). 

Eventually the corrupted screen fixed itself and Notepad became responsive.  AOO was still unresponsive until it suddenly jumped to 4 pages wide (71%).  AOO  still would not scroll with mouse wheel or scroll bars.  CPU 62% Memory 2GB (4GB  installed).  Some pictures are overlaying themselves or other pictures.  Notepad again unresponsive, then starts working again.  PC is completely unusable.  It is now 13 minutes since I opened the file at Step 6.

8 Wait a further 5 minutes.  AOO is still frozen.

9.  I have Notepad overlaying fullscreen AOO.  When I attempt to minimise Notepad it remains on display and does not minimise - the remaining Notepad screen is unresponsive presumably because Notepad is minimised.  When I expand Notepad from the toolbar, Notepad is responsive.

10 Abandon test at 21 minutes after opening file - AOO will still not scroll.

I have posted test.odt as https://www.dropbox.com/s/43wms8jscrdxvew/Test.odt?dl=0

(In reply to John from comment #7)
> After having pasted image 14, all the previous 13 images disappeared and I
> got  empty frames with an error message - it was Read Error? or Frame error?
> - I cannot recall.

See Issue 126970 - Lost images while editing a Writer .odt file - two scenarios at https://bz.apache.org/ooo/show_bug.cgi?id=126970 where images are lost.

During my tests I was using 4.1.5 as downloaded, and My Tools > Options > memory settings were the default, namely:
Graphics cache:  20 MB, 5.2 MB per object, Remove after 10 minutes.  20 Objects.

AutoRecovery was set to ON, every 15 minutes.