I have some pdf presentations (made with beamer) which have from ~800 to ~1100 slides and weight 3.7MB. When I open the pdf with muPDF, Evince or Acrobat Reader 9 for Linux the content shows up almost instantly, while when I open it with Okular it takes > than 1 minute for the contents to show up. This happens with an Atom CPU, if I open the same file on a i7 PC it takes less than 1 minute but still considerably more than other readers and way too much time considering it's an i7 PC. Setting the "greedy" option makes no difference. Please let me know how can I attach one of the files so that devs may tray it. Reproducible: Always Steps to Reproduce: 1. open the attached pdf 2. 3.
Use the "Add an attachment" or the file is too big for it?
I'm not sure, I tried several times but i get a timeout error. May I send the file somewhere else?
uploaded here: http://www.speedyshare.com/ry2Az/test.pdf
Got it, will have a look when get some time
Just that i don't forget for the future. Seems like something inside poppler-qt4 is resolving lots of named destinations, which doesn't make much sense, named destinations should be resolved on "use" time.
*** Bug 333999 has been marked as a duplicate of this bug. ***
Solution: We need to add to poppler a way to get the annotations but excluding the LinkAnnotations. For these kind of files, getting the LinkAnnotations is expensive and what is more interesting, we don't use them on the Okular side, so it's just wasted time ^_^
Git commit 19a216a275859e38a12524ee988948a5a2c2eb27 by Albert Astals Cid. Committed on 11/05/2014 at 16:43. Pushed by aacid into branch 'master'. Don't ask for link annotations, they are slow and we don't use them Needs poppler 0.28 that is yet to be released M +15 -3 cmake/modules/FindPoppler.cmake M +3 -0 generators/poppler/config-okular-poppler.h.cmake M +18 -0 generators/poppler/generator_pdf.cpp http://commits.kde.org/okular/19a216a275859e38a12524ee988948a5a2c2eb27
Thanks Albert. I've tested Okular trunk with poppler trunk (by just defining HAVE_POPPLER_0_28) and it loads pdfs much faster now. Here's a document that still loads somewhat slowly on my machine: trippelsdorf.de/style.pdf Please take a look if you find time.
Please open a new bug.
(In reply to comment #10) > Please open a new bug. It takes ~4 seconds to open that document. I can live with it. Lets just drop the issue, because it's not that important.
I just updated to poppler 0.28.1 but I still see noticeable delays for many PDFs. Consider for example the PGF manual (which has lots of internal links) http://mirrors.ctan.org/graphics/pgf/base/doc/pgfmanual.pdf with muPDF it opens in less than a second, with Okular it takes 30 secs with a intel i7, much more with a netbook processor. Should I file another bug?
(In reply to Dave Lepore from comment #12) > I just updated to poppler 0.28.1 but I still see noticeable delays for many > PDFs. Consider for example the PGF manual (which has lots of internal links) > http://mirrors.ctan.org/graphics/pgf/base/doc/pgfmanual.pdf > > with muPDF it opens in less than a second, with Okular it takes 30 secs with > a intel i7, much more with a netbook processor. > > Should I file another bug? It opens almost immediately for me.
Do you have the problem with the file that was attached here? If not, open a different bug.
I still have the problem with the file (that was) attached here. It seems to me that it is the same problem as of the PGF manual. Does the PGF manual opens instantly for you? I fear it may be a local problem here... Is there something I can do to check if it is a local problem?
(In reply to Dave Lepore from comment #15) > I still have the problem with the file (that was) attached here. It seems to > me that it is the same problem as of the PGF manual. Does the PGF manual > opens instantly for you? Yes. >I fear it may be a local problem here... Is there something I can do to check if it is a local problem? Well, as I wrote in comment 9, you need to make sure HAVE_POPPLER_0_28 is defined. I used the following patch: diff --git a/cmake/modules/FindPoppler.cmake b/cmake/modules/FindPoppler.cmake index 6389a625d3ba..429024bcfd2e 100644 --- a/cmake/modules/FindPoppler.cmake +++ b/cmake/modules/FindPoppler.cmake @@ -129,8 +129,6 @@ check_cxx_source_compiles(" #include <poppler-qt4.h> int main() { - Poppler::Page *p = 0; - p->annotations( QSet<Poppler::Annotation::SubType>() << Poppler::Annotation::ASound ); return 0; } " HAVE_POPPLER_0_28)
Why would you do that? You're essentially removing the check for 0.28
(In reply to Albert Astals Cid from comment #17) > Why would you do that? You're essentially removing the check for 0.28 Sorry, I can't remember, just found the diff in my git tree. So it was necessary at one point.
Markus, if you don't know why youre suggesting things, please don't. Dave, are you sure you have recompiled okular after installing poppler 0.28?
I installed poppler via the Archlinux packages, I think the problem might be that the okular package has not been rebuilt after poppler was upgraded. Will check with the mantainers and report back.
So, after a rebuild everything works fine. Sorry for the noise and thanks for fixing this.