After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 641261 - rendering EPS, PS extremely slow
rendering EPS, PS extremely slow
Status: RESOLVED NOTGNOME
Product: evince
Classification: Core
Component: PS
2.30.x
Other Linux
: Normal normal
: ---
Assigned To: Evince Maintainers
Evince Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-02-02 16:17 UTC by Jiri Kolafa
Modified: 2011-02-20 08:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
compressed EPS file (120.72 KB, application/x-bzip)
2011-02-02 16:17 UTC, Jiri Kolafa
Details

Description Jiri Kolafa 2011-02-02 16:17:29 UTC
Created attachment 179898 [details]
compressed EPS file

Rendering of some (not extremely) large EPS and PS files is extremely slow. The attached file (uncompressed) takes about 4 minutes to appear (on Intel Core Duo 3.33 GHz, 8GB RAM). The same if this EPS is inserted into a LaTeX file and transformed into PS. 
Direct rendering is fast (0.2 s), using command:
  /usr/bin/gs -sDEVICE=pbmraw -r1200  -q -dSAFER -dNOPAUSE -sOutputFile=problem.pbm -I. -- problem.eps
Conversion to PDF is fast (0.3 s).
Evince shows the resulting PDF fast (<0.5 s).
Comment 1 Andreas Becker 2011-02-19 11:51:58 UTC
This PS file contains ~3300 lines like „<x> <y> lineto“ for the graph in a diagram.
The file is only rendered fast when antialias is turned off. I tried this in gs and gv with disabled antialias in the ghostscript settings.

As a solution, evince (or libspectre) could have a rendering time limit, after which the document is displayed without antialiasing or the antialias algorithm has to be optimized in ghostscript.
Comment 2 Jiri Kolafa 2011-02-19 16:30:41 UTC
> The file is only rendered fast when antialias is turned off. I tried this in gs
> and gv with disabled antialias in the ghostscript settings.

Yes, the antialiasing algorithm seems to cause the problems:
- gv with antialiasing is slow for both pdf and eps
- evince is slow for eps but fast for pdf 
Looks like evince calls gv (ghostscript or the same library) for eps, but uses another (better) antialiasing scheme for pdf.

In addition, the number of gray levels differ (for rendered lines, not fonts):
- slow gv emits 4 gray levels (hex: 00 55 AA FF)
- slow evince for eps emits also 4 gray levels 
- fast evince for pdf gives all gray levels (although not equally distributed)

I am a bit confused what is inside gv because when I want to do antialiasing "manually", I generate an enlarged 2x or 3x B/W picture and rescale it (with correct gamma) to gray 1/2 or 1/3. It's slower, but not SO slow. Four equidistant levels 00 55 AA FF do not seem to be a good antialiasing result (with correct gamma), yet it takes so long.
Comment 3 Andreas Becker 2011-02-19 17:19:45 UTC
Evince uses poppler to render pdf and libspectre as a wrapper for ghostscript to render ps and eps. I can confirm that the converted pdf is rendered fast with evince/poppler but also slow with ghostscript's antialiasing.
So, this is a ghostscript bug.

I filed a bug at http://bugs.ghostscript.com/show_bug.cgi?id=691984.

By the way, gv/ghostview is a completely ghostscript based viewer.
Comment 4 Jiri Kolafa 2011-02-20 08:57:52 UTC
OK.  I therefore mark this bug as "resolved" because it is caused by a different piece of code, not evince itself. 

Note: The problematic file contains as many as 33000 lines, not 3300.
If shortened to 3300, ghostscript renders it within ~2s while poppler (evince/pdf) in < 0.2s. The ghostscript algorithm seems to scale badly with the number of objects shown.