Download it now!
Bug 41407 - EDITING: Presentation documents with a large number of complex EPS graphics renders very slowly.
Summary: EDITING: Presentation documents with a large number of complex EPS graphics r...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
3.3.4 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL: http://www.physics.smu.edu/olness/ftp...
Whiteboard: BSA target:4.2.0
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-02 14:04 UTC by Fred Olness
Modified: 2015-09-11 07:05 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
perf record trace (162.12 KB, text/plain)
2011-12-08 04:01 UTC, Victor Jimenez
Details
first slides of mentioned above presentation (2.91 MB, application/vnd.oasis.opendocument.presentation)
2012-03-22 09:45 UTC, sasha.libreoffice
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Fred Olness 2011-10-02 14:04:59 UTC
Bug in LibreOffice Presentation 

-----------------------------------------------------------------------
BRIEF DESCRIPTION OF BUG: ===================

Presentation documents with a large number of complex EPS graphics renders
very slowly.

Additionally, LibreOffice does not appear to efficiently store the
rendered screen-image. Thus, as the file is being edited, LibreOffice
continually tries to update the EPS graphics, and this results in the
computer effectively being frozen after each edit for a few minutes
until all the graphics can be re-rendered.

-----------------------------------------------------------------------
TESTED ON:   ===================

I have only tested this on Linux.

-----------------------------------------------------------------------
SOFTWARE:   ===================

Observed bug LibreOffice 3.4.3, 3.4.2, and 3.3.x

I have also observed this bug in various OpenOffice versions going back to
version 2.4.

The bug does NOT appear to be present prior to version 2.4.

-----------------------------------------------------------------------
HARDWARE:  ===================

I do not think the bug is hardware dependent. 

Observed bug on a number of computers including Dell Latitude E6510,
Dell Latitude 2100, Dell Latitude 2120, and IBM ThinkPad T43.

-----------------------------------------------------------------------
OPERATING SYSTEM:  ===================

I do not think the bug is related to a specific Linux OS. 

I have observed this bug on various version of Ubuntu including 9.10,
10.4, 10.10, and 11.4. 

-----------------------------------------------------------------------
SAMPLE FILE:  ===================

While any file with a large number of EPS graphics should produce this
bug, I have posted a sample on the web at:

http://www.physics.smu.edu/olness/ftp/misc/linux/BugTestEPS.odp

This is a relatively large file (10MB) to clearly demonstrate that it
can really lock-up the machine.

I've tested with some smaller files, and the rendering delay is
annoying, but it does not completely "hang" the machine.

The bug is not unique to this file. I give many presentations
which are typically 50 to 100 pages in length with a file size 
of 5MB to 10MB, and any one of these will produce the bug. 


-----------------------------------------------------------------------
TO REPRODUCE THE BUG:  ===================

Open an Presentation document with a large number of complex graphics. 
Go to "Slide Sorter" view: 
  "View" -> "Slide Sorter"

At this point, Presentation will use "gs" and "convert" to generate screen
previews.  You can monitor this with "top -d1"

Complex EPS images may take up to 10 seconds to render, so if you have
60 images, that's about 10 minutes or so.

Once the images are rendered, Presentation does not store them efficiently
so they can be easily re-used. If you now start to edit the file,
Presentation will re-render the EPS files on the fly. Because each pass
through the file take 5 to 10 minutes to render, the computer is
essentially "locked-up" until Presentation can catch up with the edits.
You will notice that "gs" and "convert" are continually being called. 

WHAT I EXPECTED: 

This time delay makes the program unusable as each edit requires the
user to wait 5 minutes for Presentation to re-render the
graphics. This delay was not present in versions before 2.4.

-----------------------------------------------------------------------
THE BUG WAS NOT PRESENT BEFORE: ===================

The bug is not present in older versions of OpenOffice;
specifically I have verified that it is NOT present in 
OpenOffice 2.3 running on Scientific Linux. 

-----------------------------------------------------------------------
AN INTERESTING EXPERIMENT  ===================

The CPU time is being taken by external calls to "gs" and "convert."
Under a system account, rename the "gs" and "convert" executables, and
then re-open Presentation. Screen previews will NOT be generated, but the
response of Presentation will be lightning fast.

Now rename the "gs" and "convert" executables back to their original
names, and re-open Presentation. Screen previews WILL be generated, and the
response of Presentation will be very slow.

-----------------------------------------------------------------------
A POSSIBLE WORK-AROUND:  ===================

If you save the "ODP" document in the older "SXI" format, the response
of Presentation seems to improve markedly (after the initial rendering).
   "File" -> "Save As" -> choose "File Type" as "sxi"

When you open Presentation, go to "Slider Sorter" view: 
  "View" -> "Slide Sorter"

Presentation will still take 5 or 10 minutes to generate the initial screen
previews.  But, after these previews are generated, the response of
Presentation is significantly faster than the speed working with the "ODF"
format.

-----------------------------------------------------------------------
AN INTERESTING OBSERVATION:  ===================

After you have converted the file to "SXI" format, you can now re-save
as "ODF" format, and the response of Presentation will be the same as with
the "SXI" format UNTIL you close the file. But, after you close and
re-open this "ODF" format document, then the response of Presentation will
be as slow as for the original "ODF" document.

-----------------------------------------------------------------------
IS THIS A DUPLICATE BUG:  ===================

I searched the database. There were a number of bug reports for
OpenOffice which may be related to this bug. For LibreOffice, I find
some bug reports that might have similar issues, but none which are
obviously identical.

Might be similar to the closed bug: Bug 40382 

-----------------------------------------------------------------------
I HAVE TRIED THE POSTED SOLUTIONS ON THE WEB:  ===================

I have tried the posted solutions on the web. Specifically, I have
adjusted the options for LibreOffice to ensure I'm not missing
something simple.

Specifically, under: "Tools" -> "Options"  ->"LibreOffice" -> "Memory"
I have the following set: 
   Undo: Number of Steps: 30
   Graphics Cache: 256MB (this is the max allowed)
   Memory per object: 5MB
   Remove from memory after:  23 hours
   Number of Objects: 100

And under: "Tools" -> "Options"  ->"LibreOffice" -> "View"
I have the following set: 
   Graphics output: "Use Anti-Aliasing"  is turned off


-----------------------------------------------------------------------
COMMENTS: ===================

Sometime after OpenOffice 2.3, the method used to render graphics on
Linux was changed.  The result is for a very complex document, it can
take 5 to 10 minutes to render the full document after each edit to
the file.

If I only had to wait 5 to 10 minutes for the rendering of the until
screen previews, I could live with that.

But, what seems to have changed in the later version is that the
graphics are continually re-rendered as you edit. Thus, a trivial edit
initiates a 5 minute re-render process, and Presentation is "locked-up"
until this finishes.  Operationally, this means every time you type,
edit, or move an object in Presentation, you have to wait 5
minutes--clearly, this makes it unusable.

-----------------------------------------------------------------------
POSSIBLE SOLUTION: #1  ===================

It appears the older versions of OpenOffice (Pre Version 2.4) dealt with 
the graphics in a more efficient manner. If one could identify what changed between
2.3 and the later versions, this might provide an easy fix. 

-----------------------------------------------------------------------
POSSIBLE SOLUTION: #2  ===================

The other solution would be to create and store screen-view images for
each EPS graphic--similar to thumbnails which are generated for JPG
photos. Clearly, it is the external calls to "gs" and "convert" that is
slowing down the process; if these could be avoided, the response time
of Presentation would be greatly improved.


-----------------------------------------------------------------------
 ===================
Comment 1 Victor Jimenez 2011-12-07 09:32:10 UTC
I have exactly the same problem. I am currently using LibreOffice 3.4.4 in Ubuntu 11.10. The problem is not new though, it has been in all LibreOffice versions since, perhaps, 1-2 years ago. As Fred is saying, in quite older versions of OpenOffice the problem was not there, but at some point it was introduced.

I can also confirm that it is not dependent on the Linux distribution, since I have seen this problem both under Ubuntu and OpenSUSE.

In my opinion, this issue really impacts the usability of Impress. Please, let me know how I can help to solve this, since that would reduce the pain that I need to go through now every time I need to create a presentation.
Comment 2 Victor Jimenez 2011-12-08 04:01:12 UTC
Created attachment 54234 [details]
perf record trace
Comment 3 Victor Jimenez 2011-12-08 04:02:46 UTC
I ran perf record on libreoffice in order to find where the execution time was being consumed. I used a file with 3-4 EPS generated with R. This is what I found (the full trace is on the attachment). I hope it helps.

    15.55%        convert  libpng12.so.0.46.0             [.] 0xbfa0          
    12.65%        convert  libz.so.1.2.3.4                [.] 0xebbe          
    10.92%             gs  libgs.so.9.04                  [.] 0x3ab52f        
     7.66%             gs  libpng12.so.0.46.0             [.] 0x101fa         
     6.06%             gs  libgs.so.9.04                  [.] 0x368580        
     4.97%             gs  libz.so.1.2.3.4                [.] 0x5887          
     3.70%    soffice.bin  libvcllx.so                    [.] 0x1a00ee        
     3.49%    soffice.bin  libvcllx.so                    [.] Bitmap::Replace(AlphaMask const&, Color const&)
     1.76%    soffice.bin  [kernel.kallsyms]              [k] 0xffffffff81031dba
     1.64%    soffice.bin  libz.so.1.2.3.4                [.] 0xe2ff          
     1.27%             gs  [kernel.kallsyms]              [k] 0xffffffff81031dba
     1.17%        convert  [kernel.kallsyms]              [k] 0xffffffff81031dba
     1.12%    soffice.bin  libfontconfig.so.1.4.4         [.] 0x8e08          
     1.08%    soffice.bin  libvcllx.so                    [.] BitmapReadAccess::SetPixelFor_24BIT_TC_BGR(unsigned char*, long, BitmapColor const&, ColorMask const&)
     1.01%    soffice.bin  libc-2.13.so                   [.] 0x11e959        
     0.85%        convert  libz.so.1.2.3.4                [.] adler32
     0.77%             gs  libgs.so.9.04                  [.] 0x15b4e0        
     0.77%    soffice.bin  libvcllx.so                    [.] BitmapReadAccess::GetPixelFor_24BIT_TC_BGR(unsigned char const*, long, ColorMask const&)
     0.74%             gs  liblcms.so.1.0.19              [.] cmsLinearInterpLUT16
     0.67%    soffice.bin  libuno_sal.so.3                [.] rtl_crc32
     0.66%        convert  libMagickCore.so.3.0.0         [.] ExportQuantumPixels
     0.60%    soffice.bin  libz.so.1.2.3.4                [.] adler32
     0.57%        convert  libMagickCore.so.3.0.0         [.] ImportQuantumPixels
     0.57%             gs  libgs.so.9.04                  [.] bits_compress_scaled
     0.56%             gs  libgs.so.9.04                  [.] names_ref
     0.54%    soffice.bin  libvcllx.so                    [.] BitmapReadAccess::GetPixelFor_8BIT_PAL(unsigned char const*, long, ColorMask const&)
Comment 4 Björn Michaelsen 2011-12-23 12:34:18 UTC
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Comment 5 Fred Olness 2011-12-28 09:51:28 UTC
v3.5.0beta2  has improved graphics handling, and the rendering of
complex graphics is greatly improved.

To test this feature, download the sample ODP document, open, and
scroll through the pages. When the document is first viewed, the
external graphics will be rendered with gs and convert; this will take
a few seconds per slide. After the slides are rendered, you can
navigate around the document and the graphics reloaded
quickly--generally within a second.

This is in CONTRAST to previous versions where as you navigate through
the document the graphics would be re-rendered on the fly, thus
locking up the machine for a minute or more.

I will test this on other machines with other documents, but unless
there are other complaints or something I'm missing, I would 
call  v3.5.0beta2 an acceptable fix and close this bug.
Comment 6 Victor Jimenez 2011-12-29 03:08:49 UTC
After trying v3.5.0beta2 I noticed that rendering has been improved. Initially, while traversing along the slides for the first time, there is a significant overhead, but later it seems to be reduced.

While this new version significantly improves usability, I wonder whether it is possible to further improve support for slides with EPS plots. I do not know whether the response time can be reduced to the level when native libreoffice drawings are used, but, in my opinion, paying 1-2 seconds every time that a slide with an EPS drawing is accessed is still too high (not too mention, the much longer initial delay the first time that the document is opened).
Comment 7 sasha.libreoffice 2012-03-22 09:35:03 UTC
Thanks for bugreport
Reproduced in 3.3.4 and 3.5.1 on Fedora 64 bit 
Changing version to 3.3.4 as most early reproducible 

Slow opening pictures is Linux only problem. On Windows they opens in about 2 seconds per picture. After 1 sec. pictures opens fuzzy, and after second 1 sec. they opens sharp. But half of pictures on Windows looks corrupted. And differs in normal mode and after press F5.

IMHO problem is in library, used for rendering such pictures. Or in interoperate with this library.
Comment 8 sasha.libreoffice 2012-03-22 09:45:07 UTC
Created attachment 58882 [details]
first slides of mentioned above presentation
Comment 9 sasha.libreoffice 2012-11-29 08:37:33 UTC
Sorry for incorrect information in Comment 7. Correct information is:
no EPS pictures on Windows shown. But metainformation such as "Creator" and "Creation date" still extracted.
Comment 10 Emmanuel 2013-05-30 10:13:51 UTC
Confirmed, and not solved with LibreOffice 3.5.7.2 on Ubuntu LTS 12.04 amd64.
I have plenty of mem, a very fast machine, and an SSD. So this is not a hardware problem.
As far as I remenber, all versions of OpenOffice/LibreOffice I've been using had the same issue.
Comment 11 Marco van Hulten 2013-06-25 15:48:07 UTC
Confirmed in LibreOffice 3.6.6.2, Fedora 18, 64 bit.  Slowness with eps-figures was experienced in both Writer and Impress.
Comment 12 Commit Notification 2013-10-02 15:09:17 UTC
Björgvin Ragnarsson committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=f5c3f5601a3739dead635f9abc446951b385018f

Improves fdo#41407: Make gs a higher priority than convert for EPS rendering.



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 13 Alex Thurgood 2015-01-03 17:38:22 UTC
Adding self to CC if not already on
Comment 14 V Stuart Foote 2015-09-11 07:05:54 UTC
Closing as Resolved Fixed

Björgvin R's work doing conversion via Ghostscript rather than Imagemagick convert as well converting to internally used BMP rather than PNG speeds things up markedly.

Attachment 58882 [details] opens without noticeable delay and scrolls briskly while embedded EPS, including those lacking preview TIFF, are rendered to BMP by Ghostscript

Please reopen if folks believe otherwise.

=-ref-=
http://cgit.freedesktop.org/libreoffice/core/commit/?id=f5c3f5601a3739dead635f9abc446951b385018f

http://cgit.freedesktop.org/libreoffice/core/commit/?id=f3123d396c8f7f175551a9bab8bc232efe602083

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7493c458780cce40f1b564b719c4445b8920f259

Tested on Windows 10 Pro 64-bit with  64-bit gs9.16 and 64-bit ImageMagick 6.9.2 Q16
Version: 5.0.2.1 (x64)
Build ID: 9a18d52abbdfbdc2ac9acebec2b92e7859eb73b7
Locale: en-US (en_US)