Summary: | EDITING: Presentation documents with a large number of complex EPS graphics renders very slowly. | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Fred Olness <olness> |
Component: | Impress | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | betabandido, Fahad.alsaidi, iplaw67, patrick.noffke, sasha.libreoffice, vsfoote |
Priority: | medium | ||
Version: | 3.3.4 release | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
URL: | http://www.physics.smu.edu/olness/ftp/misc/linux/BugTestEPS.odp | ||
Whiteboard: | BSA target:4.2.0 | ||
Crash report or crash signature: | Regression By: | ||
Attachments: |
perf record trace
first slides of mentioned above presentation |
Description
Fred Olness
2011-10-02 14:04:59 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. 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) |