Some epubs take forever before opening (rendering the first page). Everything looks like Okular freezes while loading the epub, then the rendering is laggy (not fast, but not freezing either). Reproducible: Always Steps to Reproduce: 1. Download the epub @ http://www.spacians.net/files/spacians.epub 2. Open it with okular and wait >20s for the first rendering. Actual Results: Freezes for >20s before opening. Expected Results: Freeze less :-) Callgrind indicates that 66% of that time is spent in libfreetype, 20% in libQtCore and 8% in libQtGUI The complete callgrind dump is available at https://transvol.sgsi.ucl.ac.be/download.php?id=7020990a32c9daaf (14 days...) This is a possible duplicate of #358562, but that bug contains nearly no information, so its har to say if this is related. The issue was first reported on NixOS (https://github.com/NixOS/nixpkgs/issues/9644) but I then tried it on ArchLinux. Guys on NixOS also reported the issue to happen on Fedora. --- Okular Version 0.24.2 Using KDE Development Platform 4.14.17
this happens with epubs with weird directory structures for the most part as per: https://git.reviewboard.kde.org/r/125500/ has a patch that fixes the loading problem in maybe half the cases, but some epubs still manage to freeze. on the log it will also show several "cannot find [path to file]/filename" errors (mainly with locating images/css). it looks like the main issue is with libepub which is not maintained, not handling the paths correctly. the patch submitter above mentions " non-canonical path in libepub. I fixed it in my fork of library" but that fork is nowhere to be found.
the referenced path does allow the ebooks to be opened faster, but the log is still full of missing path/file errors
It seems to me that it is unrelated. My log shows nothing like "cannot XXX". What log are you referring to ? And the attached epub has a very simple structure, and there seem to be no error in libepub. Have you tried the attached epub in okular ?
Created attachment 97705 [details] okular-frameworks-git log from konsole >Have you tried the attached epub in okular ? indeed, running latest git okular-frameworks-git r7262.154c98f-1 (Sat Mar 5 22:50:10 CST 2016) from konsole, see attached file all the libepub missing files are the same as on the link mentioned running the patched version from the link provides a few more details: libepub (II): cover.xhtmlstylesheet.css - No such file libepub (II): cover.xhtmlcover-image.jpg - No such file libepub (II): cover.xhtmlcover-image.jpg - No such file libepub (II): title_page.xhtmlstylesheet.css - No such file libepub (II): title_page.xhtmlcover-image.jpg - No such file libepub (II): title_page.xhtmlcover-image.jpg - No such file libepub (II): ch1.xhtmlstylesheet.css - No such file libepub (II): ch1.xhtmlcover-image.jpg - No such file libepub (II): ch1.xhtmlcover-image.jpg - No such file libepub (II): ch2.xhtmlstylesheet.css - No such file libepub (II): ch2.xhtmlcover-image.jpg - No such file libepub (II): ch2.xhtmlcover-image.jpg - No such file libepub (II): ch3.xhtmlstylesheet.css - No such file libepub (II): ch3.xhtmlcover-image.jpg - No such file libepub (II): ch3.xhtmlcover-image.jpg - No such file and as mentioned in the link, the structure of the epub (if you open in ark for example) is what throws off either libepub or okular (or both)
the files are obviously there, but somewhere along the way either okular or libepub add a kUrl path that causes the files to be lost in the process (ie.. instead of finding the file "cover-image.png" in the root of the epub, it tries to find it in some path added by kURL in either libepub's implementation or okular's)
(In reply to Albert from comment #4) > Created attachment 97705 [details] > okular-frameworks-git log from konsole > > >Have you tried the attached epub in okular ? > indeed, running latest git okular-frameworks-git r7262.154c98f-1 (Sat Mar 5 > 22:50:10 CST 2016) from konsole, see attached file > all the libepub missing files are the same as on the link mentioned Then your issue could be different: okular-frameworks is unsupported, and it could suffer from porting errors related to paths.
>Then your issue could be different: okular-frameworks is unsupported, and it could suffer from porting errors related to paths. you're right in regard to frameworks. I can however confirm your original report: >Okular freezes while loading the epub, then the rendering is laggy (not fast, but not freezing either). in regular okular, and the log displays the same information as I posted sans the "no such file" portion Name : kdegraphics-okular Version : 15.12.2-1 Qt: 4.8.7 KDE Development Platform: 4.14.17 Okular: 0.24.2
So we agree on the bug, and it is reproducible. That's a great start. Do any of you have an idea on how to debug this ? Is it possible to get traces without recompiling ?
*** Bug 360057 has been marked as a duplicate of this bug. ***
I should note that per the duplicate bug, this EPUB also exhibits the problem and Okular should be verified to properly work with it - http://www.shlomifish.org/Files/files/text/Up-and-Coming-Stories-by-the-2016-Campbell-Eligible-Authors-anthology.epub - here it also crashes eventually with it.
Investigations show that okular spends a lot of time in the convert() method. That step produces a QTextDocument from the epub content. More specifically, it spends a lot of time in _cursor->insertHtml() called once for each chapter of the epub, and an equal amount of time in _cursor->insertText() used very stupidly by the algorithm to force a page break. Also, the console output shows that okular repaints all the pages on every redraw, which causes that other 50% of the load time, and causes lag during scrolling. I have attached a first patch to remove the dumb insertion of newline characters to force a new page. The patch also tries to group cursor operations. That being said, my patch does not seem to have that much effect on the load time.
Created attachment 97741 [details] Ipmprove line breaks and batch cursor edits
Please use reviewboard.kde.org for patches
After many bissecting builds, my feeling is that there is not a single commit to blame, but a set of changes that decrease paerformance on the underlying QTextDocument. QTextDocument is quite bloated and, most probably, received extra features (or even bugfixes) at the cost of efficiency. If you want an efficient epub reader, use calibre's document viewer.
Guillaume since you're not an Okular developer, don't WONTFIX bugs.
Sorry, that was a bit bold from me.
Git commit c110c65401a97877eb8b1cd3c6be04e2bdcbc5ec by Martin T. H. Sandsmark. Committed on 13/07/2016 at 13:41. Pushed by sandsmark into branch 'frameworks'. Improve page breaks and batch up cursor edits in epub generator Patch by Guillaume Maudoux (layus). M +14 -11 generators/epub/converter.cpp http://commits.kde.org/okular/c110c65401a97877eb8b1cd3c6be04e2bdcbc5ec
(I reverted that change later, it broke layouting). For Reasons(TM) I implemented a trivial epub "reader" using KArchive and QDomDocument for parsing the container and QTextDocument for the actual rendering: https://github.com/sandsmark/epubreader The performance of this seems to be as good as or even better than FBReader and Calibre, depending on the book. I ran my application under callgrind, and it seems like there's some low-hanging fruit in the internal QCss class to increase performance even more. I plan on using the code from that to improve the epub generator in Okular.
Nice ! I hope it will find its way in okular fast enough :-).
Any new information on this bug ? Still affecting okular 0.25
I am running Fedora Kinoite Rawhide amd64 (immutable-base distribution) currently on Plasma 5.22. I have installed Okular 21.04.2 from Flatpak. My system is a Ryzen 2500U with 16GB RAM and /home on btrfs on a SATA 6Gbps SSD. Under default performance settings, Okular uses 100% of a single CPU core for approximately five seconds while opening the file, and then another four seconds per individual page turn. This is the single worst performance I have ever seen of any epub renderer on any system. I attempted to trade memory usage for performance by disabling "Enable transparency effects" and setting "Memory usage" to "Greedy" in the Performance tab of the "Configure Okular" menu. The file took over ten seconds to open, a process which was still pegging a single CPU core. Page load time was decreased by 25% to three seconds, and pages that had already been rendered once opened near instantly. This suggests a pair of bugs: 1. The parser takes far too long to load an epub file or a portion of it into memory. 2. The renderer is extremely slow, and should probably be replaced with QtWebKit or QtWebEngine. The entire point of basing EPUB on HTML is that performant generation/parsing/rendering libraries are universal on every system capable of making a modern TLS connection to obtain such files. We should use one. To reproduce, simply open the following public domain EPUB file in Okular: https://gutenberg.org/ebooks/10
I can confirm the same behavior on Debian/unstable with Plasma 5.22.2, Okular 21.04.2, all native (no flatpak or other systems). I tried other viewers (mupdf, calibre ebook, atril) all of which worked without hiccup and much faster.
This issue still exists and makes reading epubs with okular a pretty bad experience. Is anyone working on this atm.?
"Is anyone working on this atm.?" It's impossible to answer this question with certainty, my guess is "no", but I can't know if some random person that I know nothing about is working on this and will submit a patch tomorrow.