Issue 127742

Summary: Severe performance degradation when multiple images anchored to same anchor? / image loss
Product: Writer Reporter: John <john.ha24>
Component: uiAssignee: AOO issues mailing list <issues>
Status: CONFIRMED --- QA Contact:
Severity: Major    
Priority: P5 (lowest) CC: monica.arzani, mseidel, ofarrwrk, petko
Version: 4.1.5   
Target Milestone: ---   
Hardware: PC   
OS: Windows 7   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---

Description John 2018-03-29 15:14:22 UTC 
Case 1 - NOT using pages:

1.  Create empty text file and add multiple new paragraphs
2.  Drag 1 x 2 MB JPG file onto page.
3.  Repeat 24 times to give file with 24 x 2MB images - images are a bit jumbled.
4.  Scroll through document.

Expected result:  Scrolling should be fast.
Actual result:  Scrolling very slow, scrolling stops.  Pictures sometimes show as broken and/or repeated.  TaskManager shows soffice.bin is consuming 50% CPU for long periods.

Download image loss test - NO PAGES.odt from https://www.dropbox.com/s/sxgv56smzki2nxe/image%20loss%20test%20-%20NO%20PAGES.odt?dl=0.  It is ~30 MB.

Case 2 - using pages - OK:

5.  Create empty text file with 24 page breaks.  
6.  Drag 1 x 2MB JPG to each page using same JPG files as above.
7.  Repeat 24 times to give file with 24 x 2MB images.
8.  Scroll through document.
 
Expected Result:  Scrolling should be fast.
Actual result:  Scrolling is fast.  

Download image loss test - WITH PAGES.odt from https://www.dropbox.com/s/o4fw44pvdv9w6u8/image%20loss%20test%20-%20WITH%20PAGES.odt?dl=0.  It is ~30MB

Conclusion.  It is the anchoring in Case 1 causing the slow scrolling.

AOO 4.1.5, Windows 7, 64 bit, 2 x 2.8 GHz, 4 GB, SSD.  
AOO Options:  GRAPHICS CACHE 20MB (as delivered), Memory per object 2MB, REMOVE FROM MEMORY AFTER 10 MINUTES.

Comments.

1  I strongly suspect the problem with Case 2 is because Writer gets into a loop when attempting to layout the document. 

What seems to happen is that Writer tries to position an image on, say, page 4. There is not enough space for the image so Writer spills some text to make room for the image > the spilled text takes the image anchor with it > which pulls the image down to page 5 > which leaves a gap on page 4 > so Writer pulls up some text to fill the gap > which pulls up the image anchor > which pulls up the image > but there is not enough space for the image > so Writer spills some text > which takes down the anchor ... and so on. [My document has no text but I copied the words from a forum post I wrote ...]

Writer eventually drops out of this loop with the image located where it was positioned when Writer pulled out and often a white space gap is left in the text. This is particularly noticeable when using Master Documents where the entire document is laid out each time the document is opened or updated.

2.  On one test, images were lost from Case 2 and replaced by placeholders.  Investigation showed that the lost images were not in \Pictures in the .odt file.

Many forum posts relate to "Writer loses images".  I strongly suspect lost images is linked with this problem.

Might a possible scenario for losing images be:

1  When scrolling, observing ...\temp shows that Writer writes the image files into ...\temp as they are flushed from the graphics cache.  Even though the document has only 24 images, ...\temp can have twice as many temporary image files in it.

2  If Writer "drops out of the loop" while writing an image file to temp, could that file not be written?  If it is not written that image is then lost from the document.

3.  Image loss was one of the four problems highlighted in 

Issue 126846 - Analysis Task: Major Recurring Data/Operation Loss/Corruption Situations 

4.  Related posts may include

Issue 125490 - Writer 4.1.1 very slow with large images, locks up with zoom out on 2 page view

Issue 126970 - Lost images while editing a Writer .odt file - two scenarios
Comment 1 Monica Arzani 2019-05-04 09:28:33 UTC 
Comments on CASE 1: 

#1 
I successfully replicated Case 1 using the sample file NO PAGES.odt with this configuration:
* Apache OpenOffice 4.5.0 AOO450m1(Build:9900)  -  Rev. 1857900 - Rev.1857900
System spec: 
* Processor: Intel(R) Core(TM) i7-6820HQ CPU @2.70GHz 
* Installed memory (RAM): 16.0 GB
* System type: 64-bit Operating system (Windows 7)
* Processor Graphics in Use: Intel(R) HD Graphics 530

Actual result: scrolling is slow and stops for seconds in the middle of pages. Images are displayed as broken, cut or repeated.
Expected result: fast scrolling, as smooth as in Microsoft World.

As a reference, I saved the NO PAGES.odt in *.doc (Microsoft Word 97/2000/XP) format and repeated the steps described in Microsoft Word 2010. 

The actual result was as expected: very smooth scrolling and no image glitches.

#2
I could not replicate the bug on a Mac computer. I followed the steps for Case 1 using the sample file NO PAGES.odt with this configuration:
* Apache OpenOffice 4.1.6  AOO416m1(Build:9790)  -  Rev. 1844436
2018-10-22 14:11:36 (Mon, 22 Oct 2018) - Darwin x86_6
System spec:
* System Version: OS X 10.11.6 (15G19009)
* Kernel Version: Darwin 15.6.0
* Processor: 1,6 GHz Intel Core i5
* Memory: 8 GB 1600 MHz DDR3
* Graphics: Intel HD Graphics 6000 1536 MB

The actual result was as expected: fast and smooth scrolling and no image glitches
Comment 2 John 2019-05-04 11:18:05 UTC 
LO 6.1 has recently (2018/2019) rewritten the image handling code to prevent image loss.  LO spent 40,000 Euros on having a professional programmer rewrite the image handling code so it was probably about six person-months of work.  See https://blog.documentfoundation.org/blog/2017/05/02/tender-improve-image-handling-libreoffice-201705-01/

Some of the LO analysis at https://blog.documentfoundation.org/blog/2018/06/19/image-handling-rework-for-libreoffice-collaboras-tender-results/ may assist in debugging the problem.

See also https://www.reddit.com/r/libreoffice/comments/7umifb/has_libreoffice_6_just_killed_the_indispensable/ and https://bugs.documentfoundation.org/show_bug.cgi?id=110448
Comment 3 Peter 2019-05-04 20:30:06 UTC 
I have a hard time to believe this helps OpenOffice. And it does not help this Issue. I suggest you write that rather in facebook. That is better place.
Comment 4 Peter 2019-05-04 20:32:46 UTC 
confirmed on test of the second post.
Comment 5 Peter 2019-05-04 20:56:16 UTC 
Sorry, reference to Facebook is a bit harsh. Rather discuss such topics on dev list (dev@openoffice.apache.org) then here. I think it is the better place.
Comment 6 John 2019-05-04 22:16:00 UTC 
(In reply to Peter from comment #3)
> I have a hard time to believe this helps OpenOffice. And it does not help
> this Issue. I suggest you write that rather in facebook. That is better place.

I was working on the basis that, as you may not be aware, LO is a fork of OOo, and much code will presumably still be common especially as there has been relatively little development of AOO in recent years.  I read the LO tender results which say:

"When images are used in LibreOffice documents, the software manages them in a “life-cycle” which includes importing, displaying, modifying, exporting and more. To save memory – especially with large documents – images that are not currently on screen are sometimes moved out of memory and saved onto disk in a technique known as “swapping” or “paging”. The goal of the tender was to improve LibreOffice in these areas, making it more efficient at handling images and modernising the code base."  

That seemed to me to be sufficiently applicable to AOO to bring it to the developers' attention especially "modernising the code base".

Let me suggest that you visit the forum (where I am a volunteer with thousands of posts) and search with los* images.  You will find you get 338 threads of which this is typical: Images disappear leaving icon of 3 squares and dots at https://forum.openoffice.org/en/forum/viewtopic.php?f=10&t=93725&hilit=los%2A+images  IT has been read  over 3,000 times.  The similar Disappearing pictures in Impress has been read 4,800 times.

We have to try and help users who are distraught at having lost work through no fault of their own.  If you go to [Tutorial] Some useful hints on using images (I wrote it) at https://forum.openoffice.org/en/forum/viewtopic.php?f=71&t=86682 and read item "16. Lost images ... and a word of caution about using AutoRecovery. LibreOffice 6.1 may now be better than AOO" you will see that I am now telling users "LO 6.1 has recently (2018/2019) rewritten the image handling code to prevent image loss and LO may therefore now be better than AOO".

In the report I wrote "Common Writer problems as seen by forum posts" (Issue 126846 - Analysis Task: Major Recurring Data/Operation Loss/Corruption Situations at https://bz.apache.org/ooo/show_bug.cgi?id=126846 you will see "Item 3. My document has lost all its graphics".  

Image loss in AOO is real and is happening repeatedly.  I reported Issue 126970 - Lost images while editing a Writer .odt file - two scenarios at https://bz.apache.org/ooo/show_bug.cgi?id=126970 and Issue 125490 - Writer 4.1.1 very slow with large images, locks up with zoom out on 2 page view at https://bz.apache.org/ooo/show_bug.cgi?id=125490

There appears to be a severe problem with AOO image handling especially in Writer and Impress.
Comment 7 Peter 2019-05-05 11:26:07 UTC 
Hi John,

so what will it change if I read all the Issues. I do not doubt there is a problem. But pointing to LO is not the solution either. It will not fix OpenOffice. 

I think the article is are to unspecific for the Bugtracker. And I also think always pointing at LO can not be the solution, at least if LO does not support the move.
You are free to promote LO for actually fixing stuff. No issues on that. Just dont do it in the OO bug tracker!

I do not want to diminish your work. Or that of anyone else. I hope I have made now more clear on my perspective.
Comment 8 roryof 2019-05-05 12:23:07 UTC 
My finding, using OO 4 (all versions up to and including 4.2.0) is that if I turn off /Tools /Options /AutoRecovery I lose no picture files.  Of course, responsibility for regular saving in case of a crash then becomes the User's, but as a long time computer User (50+ years) I do this instinctively.  

I have just completed preparing a presentation consisting of 100 slides (75 to be selected according to audience), 37.5 hours editing, 250 saves, containing 180 images, on computers using Xubuntu 18.04.2 with no crash or loss of pictures.  I am also in process of updating various previous presentations and have had and expect no picture loss with the above setting.  The last Writer document I prepared containing illustrations also gave no problems. 

Previous experience (circa 4.0) suggests that if I enable Autorecovery I run risk of losing pictures.

My thoughts are that OO does not satisfactorily preserve the entire OO environment around the AutoRecovery Save operation.