A store published a pdf that is a one page table. This page takes around 150 seconds to be displayed. Machine=amd athlon 2600, 512MB ram, Fedora Core 6, gnome desktop: evince-0.6.0-6.fc6 poppler-0.5.4-5.fc6 cairo-1.2.6-1.fc6 During opening, gkrellm shows 99% cpu use (firefox is open). This reduces to ~0-1% once the pdf is visible. There is a logo in the top right, the table lines do not make a full grid, they are more single lines. $ file VIC_tradinghour.test_long_time_to_open.pdf VIC_tradinghour.test_long_time_to_open.pdf: PDF document, version 1.4 $ ghex copy-paste: of header: %PDF-1.4 ?????? 1 0 obj<</Count 1/Type/Pages/Kids[6 0 R]>> endobj 3 0 obj<</CreationDate(D:20061117112004+11'00')/Creator(Adobe InDesign CS2 \(4.0.2\))/Producer(Adobe PDF Library 7.0)/ModDate(D:20061123110533+11'00')/Trapped/False>> endobj 5 0 obj<</ViewerPreferences<</Direction/L2R>>/Metadata 56 0 R/Pages 1 0 R/Type/Catalog>> endobj $ pdfinfo VIC_tradinghour.test_long_time_to_open.pdf Creator: Adobe InDesign CS2 (4.0.2) Producer: Adobe PDF Library 7.0 CreationDate: Fri Nov 17 11:20:04 2006 ModDate: Wed Dec 20 09:38:22 2006 Tagged: no Pages: 1 Encrypted: no Page size: 510.236 x 1247.24 pts File size: 616264 bytes Optimized: no PDF version: 1.4 $ pdf2text completes in less than a second. text doc stats: lines=21 words=5380 chars total=16327 chars except space=16327 Note: during opening: after about 1 minute the CPU fan comes on to full speed.
Created attachment 8472 [details] pdf with poor opening performance in evince/poppler
Created attachment 8473 [details] screen shot of final rendering. Seems simple enough !
For a comparison check, I booted windows 98se, ran adobe acrobat reador 5.04 and opened the attached pdf. It was visible within one second. I notice the pdfinfo shows: not optimized and the pdf does contain a graphic. Perhaps the graphic is like a 500kB jpeg that needs to be rendered before the rest of the document is displayed ?
Still present, Splash 500ms, Cairo 7800ms
It takes 4.5 seconds with current poppler.
hmm, it seems we are clipping too much. Removing out->clip(state); from Gfx::doEndPath() fixes the problem (it renders in 0.55 seconds) and provides the same output in both backends. I wonder why we need to clip in Gfx::doEndPath().
See http://www.parkweb.vic.gov.au/resources05/05_1413.pdf for a file that needs that clip call there
*** Bug 11809 has been marked as a duplicate of this bug. ***
*** Bug 12266 has been marked as a duplicate of this bug. ***
Just as a reference timing: Opening the opening hours pdf (attach1) takes: - 5 seconds [new machine with amd quad 3GHz CPU] gkrellm shows 100% CPU for those 5 secs for one of the CPU cores. It seems to be something about the use of long columns or tables that is common between these pdfs. Document Viewer 2.26.2 using poppler 0.10.7 (cairo). on Fedora 11.
0,3 seconds with current cairo! See commit: http://cgit.freedesktop.org/cairo/commit/?id=85094c4eee4e50ec724bf1bb54ecff6f7c1014bf Thanks Chris!
*** Bug 13525 has been marked as a duplicate of this bug. ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.