Bug 198566 - Slow on some documents when using big zoom and search
Summary: Slow on some documents when using big zoom and search
Status: REPORTED
Alias: None
Product: okular
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Debian testing Unspecified
: NOR wishlist
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-01 20:50 UTC by Alex Dănilă
Modified: 2020-02-24 21:18 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Dănilă 2009-07-01 20:50:10 UTC
Version:            (using KDE 4.2.4)
Installed from:    Debian testing/unstable Packages

Some documents with big graphics can make Okular browsing very slow if you zoom a lot. 

One such document is here http://www.ptc.com/appserver/wcms/standards/fileothumbredirect.jsp?&im_dbkey=63973&icg_dbkey=841

This document contains a somewhat big resolution image. Zoom to maximum, search for something ("tolerance" for example) and notice how dragging gets slow.

I make this only a wish, because these are extreme cases, but it would be nice to have Okular fast in any situation someday.
Comment 1 Mahendra Tallur 2018-08-08 10:19:31 UTC
Hi ! This bug report is probably too generic but...

I noticed some PDFs generated with AutoCad made Okular extremely unresponsive **even though they are displayed quickly with evince with the same libpoppler**. 

For instance, under Evince, they take 1.5 second to first display ; in Okular, it's closer to 10-15 seconds. It gets worse when zooming and scrolling -- it takes more time and some parts flicker, etc.

Please let me know if you are interested in looking at such a file. They contain private stuff, I cannot share them here unfortunately.

(configuration : KDE Neon ; Kubuntu 18.04 ; Ubuntu 18.04 ; KDE Apps 18.04)
Comment 2 Mahendra Tallur 2018-08-08 10:24:16 UTC
My mistake : the files I referred to were generated with ARCHICAD (and PDFTron) ; not AUTOCAD.
Comment 3 Oliver Sander 2018-08-08 11:41:16 UTC
Hi Mahendra, yours seems to be a separate bug: notice how the original bug report is about slowdown *when searching*.  Please file a separate bug report for your problem, and if at all possible try to construct a test file that you can share.
Comment 4 Mahendra Tallur 2018-08-08 11:47:56 UTC
@Oliver : thanks for your quick reply ! Hmm, the problem is I cannot produce such a file, it was made by an architect... Could I share it only with the Okular developers maybe ?

Second problem is my bugreport description would be quite generic. It basically takes way too much time to render :)

Thanks again !
Comment 5 Oliver Sander 2018-08-08 11:51:20 UTC
You may find individuals who are motivated and skilled enough to look at your file, and send it to them in private. But really, please first open a new bug report.
Comment 6 postix 2020-02-24 13:53:59 UTC
Can confirm it with the PDF I sent Albert at #418086. Zooming in while a page with a huge image renders makes Okular 1.9.2 totally unresponsive for me.
Comment 7 postix 2020-02-24 13:57:59 UTC
That means, the UI becomes unresponsive, while in the background the rendering seem to continue as the CPU load stays at 25% (1 of 4 cores). Additionally Okular throws "Bogus memory allocation size" in the terminal while filling up all 16 GB of RAM.


EDIT: When I tried to reproduce it a second time, everything seem to work as expected. Weird. I will report back if I can reproduce it more reliably.
Comment 8 Alex Dănilă 2020-02-24 21:18:15 UTC
Regarding the document I originally indicated when posting the bug: it now works very well. However, this computer is probably 5 times faster even on single thread and I don't have a slower one around.