| Summary: | too long to open and operate with http://www.dante.de/events/dante2011/programm/vortraege/folien-ts.pdf | ||
|---|---|---|---|
| Product: | MuPDF | Reporter: | Pablo Rodríguez <ghostscript> |
| Component: | mupdf | Assignee: | Tor Andersson <tor.andersson> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | sebastian.rasmussen |
| Priority: | P4 | ||
| Version: | unspecified | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Customer: | Word Size: | --- | |
|
Description
Pablo Rodríguez
2011-09-14 18:16:18 UTC
I did a very quick analysis of this PDF. Each page refers to 4 0 R as its Shadings dict. It contains 20199 radial shadings, most of which are identical. Thus I can probably safely say that the fonts are not at issue here.
Page two of the PDF has a line of blue/teal dots towards the bottom of the page, presumably indicating to the slide number (as the dots increase with the slide number). On page two there are two dots are drawn 34 times on that page and each drawing of a dot has its own (often identical) shadingpattern. Thus on page two there are 68 shadings. Worth noticing is that there are 34 pages in the PDF. Computing 34 * 2 + 34 * 3 + 34 * 4 + ... + 34 ＊ 33 ＋ 34 ＊ 34 ＝ 20196 which roughly equals the number of shadings.
pdfinfo is probably extremely slow in this one since I believe that it contains multiple O(N^2) loops. Finally, I believe that once pdfclean -dggg has been fixed it may (when run repeatedly) be able to optimize this file quite significantly given that the shading objects are identical, but doing so would take a very long time.
This file was generated by LuaTeX/ConTeXt:
Info object (41169 0 R):
<<
/Producer (LuaTeX-0.65.0)
/Creator (ConTeXt - 2011.03.30 11:21)
>>
I doubt that this file can be rendered quickly in any PDF viewer given the enormous number of objects to draw. Basically my conclusion is that this file is extremely unoptimized which results in abnormally long rendering times...
The file opens quickly on my slow machine. It's probably been fixed as a side effect of commits to optimize large dictionary objects by sorting. (In reply to comment #2) > The file opens quickly on my slow machine. It's probably been fixed as a side > effect of commits to optimize large dictionary objects by sorting. Many thanks for your reply, Tor. I guess that there are different issues here. Opening the file has been improved a lot: $ time mupdf folien-ts.pdf real 0m1.841s user 0m0.451s sys 0m0.023s But mupdfinfo needs too much with this file: $ time mupdfinfo folien-ts.pdf real 12m48.983s user 12m45.930s sys 0m0.234s pdfinfo and pdffonts are way faster: $ time pdfinfo folien-ts.pdf real 0m0.415s user 0m0.066s sys 0m0.013s $ time pdffonts folien-ts.pdf real 0m0.179s user 0m0.166s sys 0m0.010s Do you really think that it isn't a good idea to take a look at this? Many thanks for your help, Pablo |