https://bz.apache.org/ooo/show_bug.cgi?id=127742
Issue ID: 127742
Issue Type: DEFECT
Summary: Severe performance degradation when multiple images
anchored to same anchor? / image loss
Product: Writer
Version: 4.1.5
Hardware: PC
OS: Windows 7
Status: UNCONFIRMED
Severity: Major
Priority: P5 (lowest)
Component: ui
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
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
--
You are receiving this mail because:
You are the assignee for the issue.
