Apache OpenOffice (AOO) Bugzilla – Issue 77068
eps rendering very slow while scrolling
Last modified: 2017-05-20 11:15:50 UTC
Whenever an odt contains an embedded postscript file (.eps), rendering of the document takes extraordinary long. The postscript seems to be rendered lazily (on demand). As one scrolls to the page containing the eps it takes about 10s to 30s to display the graphic, freezing the whole application (Centrino 1,4 Ghz, 2GB RAM, Linux). A faster (threaded?) renderer or another loading strategy could perhaps mitigate the problem.
MRU->WG: could you please have a look?
Created attachment 44927 [details] example odt with integrated eps
I created an example document an put in the attachment.
Sorry, but this has to be a writer problem. Scrolling seems not to be a problem here. Maybe the Office version used is not the original OOo version...
I'm using the Ubuntu 7.04 OOo-package
Reassigned to SBA.
confirming the issue with vanilla OOo 2.2.0 convert takes quite some time to convert the eps to png, hence the delay. OOo 2.2.0 seems to no longer save the generated preview along with the eps (it did so in previous versions), so the preview is generated everytime the document/picture is loaded. (OOo tries to use pstoedit, convert and ghostscript in that order to generate a preview when the eps doesn't contain one) PS: ghostscript is faster, but at least my version creates a broken result (protrait result, with a major part cut-off - it only shows 5 column-groups) PPS: the commands OOo uses are (files from stdin to stdout): convert -density 300x300 eps:- png:- gs -dBATCH -dNOPAUSE -dPARANOIDSAFER -dEPSCrop -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -r300x300 -sDEVICE=png256 -sOutputFile=- - (see goodies/source/filter.vcl/ieps/ieps.cxx)
SBA->OD: I spoke to AW and PL and they told me that the problem is in Writer. Please have a look.
I can confirm this and it *is* heavily annoying, especially with complex EPS files like MATLAB output. See also Ubuntu bug 115052: https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/115052 I was totally confused at first because this *used* to work fine (as I remember). Scroll to the end of the report to see the results. :-)
according to release status meeting -> 3.x
I had a look at this (I'm using the Ubuntu version 1:2.4.1-1ubuntu1). Of course it takes a while to generate the preview initially using convert or gs, this is unavoidable, but the real problem is the cached image keeps getting swapped out. It appears that SwGrfNode::SwGrfNode calls GraphicObject::SetSwapStreamHdl without the second (nSwapOutTimeout) argument. Therefore, presumably, the timeout defaults to zero... I fixed the problem by hard-coding a reasonable timeout. I notice in the "Memory" options section there is a "Remove from memory after" option, presumably you would want to use this. BTW apologies if this was caused by an Ubuntu patch, but the discussion on the Ubuntu bug tracker seemed to indicate it belongs upstream.
*** Issue 96093 has been marked as a duplicate of this issue. ***
Does this bug affect all kind of vectorial images? i have an odt with SVG images and it is really slow as eps.
OD->rocco83: I do not know, if this issue also applies to SVG images. I propose that you submit a separate issue for SVG images.
I'm still seeing this issue in OOo 3.2 on Ubuntu 10.04. I have EPS files that I have generated using Matplotlib, and they are inserted into my writer document using Insert-->Picture-->From File. Now that I have a few images in my document, I am noticing scrolling speed to be so slow as to be annoying, with delays of 5 seconds or more when an EPS comes into view. Clearly the images are not successfully being cached, and I can see a strong spike in CPU activity every time the images appears. If I run 'top' at the same time, I can see that the program "convert" is being run and that is what is responsible for the delay.
First a substantive comment and then two administrative remarks. Clearly the cpu time is being consumed by convert/gs. A threaded renderer would be a kludge at best since the document would be incomplete until the figures loaded. The real solution is to speed up the import process. Does anyone know how OO 2 imported EPS files? Up until a year ago, I ran Fedora Core 4 (and whatever version of OO was last updated by FC4) on a much slower machine, yet EPS imported with minimal hesitation. Perhaps it simply rendered at a lower resolution? (although I never noticed low quality, even when printing posters) Or does anyone know how evince renders EPS? If the difference boils down to render resolution, perhaps this could be a user-configurable option. Administrative notes: 1) This affects oodraw and ooimpress as well as the currently tagged oowriter. Not sure if there is a way to change this issue to indicate multiple components. 2) This appears to be a duplicate of issue 99537 and potentially issue 103531 (by summary, although text suggests potentially otherwise)
Hello, the main problem is that scrolling is hampered. If every page has an EPS image, it is a total nuisance to scroll and reach the page desired. > (...) since the document would be incomplete until the figures loaded. Why would this be a problem ? If rectangular boxes were put where the images will load, it's not a problem. They just need to use the EPS bounding box. Your idea about decreasing the rendering resolution is interesting, but it will lead to a problem. The user who is interested in one precise image want to see this image with a good resolution and does not care about the other images. Also the rendering time can not be improved infinitely and gv is quite quick. Note : the problem is increased when images are included as links instead of being embedded. To my opinion, a lazy handling of the images is a must. When the user scrolls, scrolling must be smooth and fast.
Maybe I'm mistaken on this, but I think the problem is GhostScript (the same thing gv uses) being *slow*. Maybe we can make it so that OpenOffice documents store the rasterized versions of EPS images, at least then those won't have to be re-renderized all the time (just (re)loaded from the file, if the memory is not enough to keep all images). (IMHO I prefer owqcd's approach, I'm used to see images loading (e.g. in web pages) while the content is already browsable), and at least it doesn't "lock" OOo.)
>> (...) since the document would be incomplete until the figures loaded. > >Why would this be a problem ? If rectangular boxes were put where the images >will load, it's not a problem. They just need to use the EPS bounding box. owqcd raises a good point -- there are (at least) two use cases: 1) For some documents, figures are essential to interpretation (e.g. a scientific impress presentation where almost every slide is a graph). In my anecdotal experience, such graphs tend to be simple EPS files for which rendering can/should be near-instant. My message earlier was written in frustration from such an case. 2) For other documents, figures are either non-essential or involve large, complex EPS files. At owqcd states, >Also the rendering time can not be improved infinitely At some point, a large enough EPS will always be slow to render, and importing a large EPS file should not bring OO to a grinding halt. So seems there are good arguments to implement an immediate display of bounding box, threaded full-detail renderer, as well as speeding up the rendering process (potentially involving an user-specified tradeoff for lower quality). I see njsg's suggestion of caching as complementary to these tasks. od, have you (or someone else) started work on this? I will look into it, but don't want to duplicate work.
I note that many EPS images, but not all, contain a 'preview' image suitable for fast on-screen rendering. I would propose that * when documents are loaded, bounding boxes are rendered without contents * a background task/thread be used to generate initial renderings based on the embedded preview image(s). * a second background task be used to generate full-resolution images suitable for the current zoom level * when document is zoomed or scrolled, the last-available rendering be rescaled (as bitmap) to create the new rendering, until a new full-resolution image becomes available. * when images go off-screen, their rendering be kept in a limited-memory cache and only thrown out when the memory is needed for a newer image. If possible without a change to the file format, I would also suggest that if an EPS is embedded that does not contain a preview image, then a preview image be added to the .odt (etc) file, so that the EPS can be rendered, at least at low resoltion, until a better rendering is possible. Perhaps some kind of 'greyed out' our 'hourglass' icon or overlay could be used to indicate that a better rendering is still being prepared. FWIW I found that even 'simple' graphs do no rendering anywhere need fast enough for uninterrupted use experience. I will attach an example of such an EPS diagram, which, when inserted, causes noticeable delay.
Created attachment 71517 [details] example of a slow-to-render EPS
@njsg : > I think the problem is GhostScript being *slow*. I remember comparing the same EPS image, included in an OO document and displayed directly from gv. Opening with gv was instantaneous while opening in OO was slower. However this was a few years ago. @grrrats : My EPS images often describe experimental setups or device structure. Even if not very complicated, the scrolling is hampered (especially if the images are included as links) The code for displaying the bonding boxes is probably kept somewhere because I remember that around 2002, OO did not render EPS images, but used to put a rectangular frame with the size of the bounding box instead (EPS images were included only when printing was done). @jdpipe : What you propose sounds good!
owqcd@openoffice.org writes: > @njsg : >> I think the problem is GhostScript being *slow*. > I remember comparing the same EPS image, included in an OO document and > displayed directly from gv. Opening with gv was instantaneous while opening in > OO was slower. However this was a few years ago. You're right, I remember gv taking more time than xpdf to render the same (PDF) document (but of course, PDF is not PS, there is no reason for poppler to do the same ghostscript does), but it is not much slow. Maybe the last time I tried this was on a way slower computer! But, indeed, convert takes longer than this, maybe ghostscript is slow when it's about rasterizing? > @grrrats : > My EPS images often describe experimental setups or device structure. Even if > not very complicated, the scrolling is hampered (especially if the images are > included as links) My last nightmare was including a LaTeX report as attachment - as I had to use the same headers and footers, I decided to add each page as a separate EPS image (so that I could generate a high quality PostScript version of the final document). It was slow, and opening the LaTeX document in gv is fast.
od->grrrats: I am currently not working on this issue. May be consulting sj and/or aw is also an option.
AW->OD: Is it a SW-specific graphic object...?
This issue still persists in OOo 3.3 (also tested 3.2.1, also present in LibreOffice 3.3) with the attached example files or any files that I generate for my use. As grrrats pointed out, issue 99537 and issue 103531 appear to be duplicates. It may be obvious to some, but I find that larger EPS files (300+ DPI) cause Impress to become unresponsive for several minutes at a time. I noticed that slowdowns are not limited to scrolling. An .odp file that contains a dozen EPS files takes minutes to load and Impress becomes unresponsive for minutes each time the user interacts with the presentation. Clicking on a different slide or clicking on an image (to move or resize) appear to trigger the generation of a new preview (the CONVERT binary). I don't see any obvious related bugs in ghostscript's bug tracker.
I have seen similar issues in LibreOffice. I've posted the details at: https://bugs.freedesktop.org/show_bug.cgi?id=41407
Reset assigne to the default "issues@openoffice.apache.org".