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. ----------------------------------------------------------------------- ===================
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.
Created attachment 54234 [details] perf record trace
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&)
[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
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.
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).
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.
Created attachment 58882 [details] first slides of mentioned above presentation
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.
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.
Confirmed in LibreOffice 3.6.6.2, Fedora 18, 64 bit. Slowness with eps-figures was experienced in both Writer and Impress.
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.
Adding self to CC if not already on
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)