Summary: | Accessing QPrinter to get the page size name is blocking if default printer is not connected | ||
---|---|---|---|
Product: | [Applications] okular | Reporter: | Samuel Johnson <esamueljohnson> |
Component: | general | Assignee: | Okular developers <okular-devel> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | aacid, anssi.hannula, dgilbert, dimanne, doktor5000, kound, lehoangphuongbg, lmenut, luigi.toscano, oliver, p.varet, pascal+kde, tessiof |
Priority: | NOR | Keywords: | junior-jobs |
Version: | 0.19.0 | ||
Target Milestone: | --- | ||
Platform: | Arch Linux | ||
OS: | Linux | ||
Latest Commit: | http://commits.kde.org/okular/1de97322e75a43a0f04b589f2e7e1a4b50836951 | Version Fixed In: | KDE Applications 15.08 |
Sentry Crash Report: |
Description
Samuel Johnson
2014-05-13 14:21:32 UTC
It's immediate here. Please run okular under gdb and attach a backtrace of okular when it's "waiting". What to do gdb okular http://www.dmhc.ca.gov/testpage.pdf run // wait for it to "hang" press control+c on the gdb window thread apply all bt // attach the output of the thread apply all bt command Here it is: http://pastebin.com/vtkNLdj9 BTW, it seems to be related to this bug: https://bugs.kde.org/show_bug.cgi?id=329740 Also just found out that okular loads the said file instantaneously if I disconnect from network. I'm using wicd. (In reply to comment #1) > It's immediate here. > > Please run okular under gdb and attach a backtrace of okular when it's > "waiting". > > What to do > gdb okular http://www.dmhc.ca.gov/testpage.pdf > run > // wait for it to "hang" > press control+c on the gdb window > thread apply all bt > // attach the output of the thread apply all bt command (In reply to comment #1) > It's immediate here. > > Please run okular under gdb and attach a backtrace of okular when it's > "waiting". > > What to do > gdb okular http://www.dmhc.ca.gov/testpage.pdf > run > // wait for it to "hang" > press control+c on the gdb window > thread apply all bt > // attach the output of the thread apply all bt command (In reply to comment #1) > It's immediate here. > > Please run okular under gdb and attach a backtrace of okular when it's > "waiting". > > What to do > gdb okular http://www.dmhc.ca.gov/testpage.pdf > run > // wait for it to "hang" > press control+c on the gdb window > thread apply all bt > // attach the output of the thread apply all bt command Correct, it's the same issue, the other one i will be able to workaround more easily than this one because they have different causes. Basically we should copy the data of the sizes over to Okular and stop asking QPrinter for it. (In reply to comment #4) > Basically we should copy the data of the sizes over to Okular and stop > asking QPrinter for it. Maybe backport from the new QPageSize class from Qt5, if not too complicated? That would simplify the future Qt5 port: http://www.layt.net/john/blog/odysseus/help_test_qtprintsupport_changes_in_qt_53_beta_1 (In reply to comment #3) > Correct, it's the same issue, the other one i will be able to workaround > more easily than this one because they have different causes. I don't understand why this happens for only a few files. This file (http://www.ncu.edu.tw/~ncu25352/Uploads/20131231103232738561744.pdf) for instance gets loaded immediately. I however face the 30 seconds delay if I click on [File -> Properties], [File -> Print] and [View -> Presentation] for *all* files. Is there a way I can completely disable printing on my copy of Okular?. I rarely print. Thanks for your efforts. On load it happens for files whose not all pages are the same. You can try setting all your printers to be non default in the cups configuration, that may help. > On load it happens for files whose not all pages are the same.
On load it happens for files whose not all pages are the same size.
(In reply to comment #8) > > On load it happens for files whose not all pages are the same. > On load it happens for files whose not all pages are the same size. I've temporarily commented 'ServerName' in cups client.conf, now okular loads super fast. Thanks for your help. *** Bug 338030 has been marked as a duplicate of this bug. *** *** Bug 342131 has been marked as a duplicate of this bug. *** # netstat -npA inet | grep okular | grep 631 | wc -l 433 So this might partially explain why cups server timeouts in my case (60secs) - okular is just flooding it with connections. Hi, I have what appears to be the same problem, or at least a closely related one. On some PDFs, when I scroll to a new page, Okular freezes for well over 30 seconds. That makes it outright unusable. :( I ran strace on the running process. Turns out Okular freezes while waiting for Avahi to resolve the IP of the currently turned off computer where the printer is plugged in. I assume that despite this slightly different detail, this is the same bug. If not, please let me know, and I'll open a new one. In the meanwhile, the only workaround I've found is to just use Evince. :/ Git commit dafd8f697285222975a0497ef6cc21e440d1369f by Albert Astals Cid. Committed on 30/07/2015 at 10:45. Pushed by aacid into branch 'master'. Bring QPageSize from Qt5 Allows us to not use a dummy printer for knowing page size Which is nice since it won't block because Qt4 QPrinter is a bit weird sometimes FIXED-IN: KDE Applications 15.08 M +1 -0 CMakeLists.txt M +40 -40 core/document.cpp A +904 -0 core/qpagesize.cpp [License: LGPL (v3)] A +239 -0 core/qpagesize.h [License: LGPL (v3)] http://commits.kde.org/okular/dafd8f697285222975a0497ef6cc21e440d1369f Git commit 1de97322e75a43a0f04b589f2e7e1a4b50836951 by Albert Astals Cid. Committed on 30/07/2015 at 10:47. Pushed by aacid into branch 'Applications/15.08'. Bring QPageSize from Qt5 Allows us to not use a dummy printer for knowing page size Which is nice since it won't block because Qt4 QPrinter is a bit weird sometimes FIXED-IN: KDE Applications 15.08 M +1 -0 CMakeLists.txt M +40 -40 core/document.cpp A +904 -0 core/qpagesize.cpp [License: LGPL (v3)] A +239 -0 core/qpagesize.h [License: LGPL (v3)] http://commits.kde.org/okular/1de97322e75a43a0f04b589f2e7e1a4b50836951 *** Bug 358634 has been marked as a duplicate of this bug. *** |