Issue 77068 - eps rendering very slow while scrolling
Summary: eps rendering very slow while scrolling
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: OOo 2.2
Hardware: PC Linux, all
: P3 Trivial with 11 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Keywords: oooqa
: 96093 (view as issue list)
Depends on:
Reported: 2007-05-08 08:45 UTC by gundee
Modified: 2017-05-20 11:15 UTC (History)
9 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

example odt with integrated eps (12.70 KB, text/plain)
2007-05-08 11:52 UTC, gundee
no flags Details
example of a slow-to-render EPS (28.33 KB, application/postscript)
2010-09-01 09:09 UTC, jdpipe
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description gundee 2007-05-08 08:45:59 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.
Comment 1 michael.ruess 2007-05-08 10:20:02 UTC
MRU->WG: could you please have a look?
Comment 2 gundee 2007-05-08 11:52:05 UTC
Created attachment 44927 [details]
example odt with integrated eps
Comment 3 gundee 2007-05-08 11:53:18 UTC
I created an example document an put in the attachment. 
Comment 4 wolframgarten 2007-05-08 12:09:23 UTC
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...
Comment 5 gundee 2007-05-08 12:18:02 UTC
I'm using the Ubuntu 7.04 OOo-package
Comment 6 michael.ruess 2007-05-09 07:32:39 UTC
Reassigned to SBA.
Comment 7 lohmaier 2007-05-11 17:54:57 UTC
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)
Comment 8 stefan.baltzer 2007-05-15 14:51:58 UTC
SBA->OD: I spoke to AW and PL and they told me that the problem is in  Writer.
Please have a look.
Comment 9 enforcer2 2007-05-18 12:21:22 UTC
I can confirm this and it *is* heavily annoying, especially with complex EPS
files like MATLAB output. See also Ubuntu 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. :-)
Comment 10 Mathias_Bauer 2007-12-03 14:49:10 UTC
according to release status meeting -> 3.x
Comment 11 pwainwright 2008-06-30 19:12:16 UTC
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.
Comment 12 michael.ruess 2008-11-27 14:52:55 UTC
*** Issue 96093 has been marked as a duplicate of this issue. ***
Comment 13 rocco83 2009-07-10 13:34:13 UTC
Does this bug affect all kind of vectorial images?

i have an odt with SVG images and it is really slow as eps.
Comment 14 Oliver-Rainer Wittmann 2009-07-13 08:13:27 UTC
I do not know, if this issue also applies to SVG images. I propose that you
submit a separate issue for SVG images.
Comment 15 jdpipe 2010-08-22 01:28:07 UTC
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.
Comment 16 grrrats 2010-08-31 21:34:21 UTC
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)
Comment 17 owqcd 2010-08-31 22:54:47 UTC

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. 
Comment 18 njsg 2010-09-01 00:16:07 UTC
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.)
Comment 19 grrrats 2010-09-01 03:16:32 UTC
>> (...) 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.
Comment 20 jdpipe 2010-09-01 09:06:55 UTC
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.

Comment 21 jdpipe 2010-09-01 09:09:11 UTC
Created attachment 71517 [details]
example of a slow-to-render EPS
Comment 22 owqcd 2010-09-01 10:46:24 UTC
@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!
Comment 23 njsg 2010-09-01 20:07:22 UTC 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.
Comment 24 Oliver-Rainer Wittmann 2010-09-06 08:18:56 UTC
I am currently not working on this issue.
May be consulting sj and/or aw is also an option.
Comment 25 Armin Le Grand 2010-09-06 11:36:14 UTC
AW->OD: Is it a SW-specific graphic object...?
Comment 26 voltaic 2011-05-04 04:22:02 UTC
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.
Comment 27 Fred Olness 2011-11-14 01:55:32 UTC
I have seen similar issues in LibreOffice. I've posted the details at:
Comment 28 Marcus 2017-05-20 11:15:50 UTC
Reset assigne to the default "".