https://bugs.kde.org/show_bug.cgi?id=507802
--- Comment #7 from Sebastian <[email protected]> --- Same problem still under Debian 13 amd64. If you give Poppler the "QString &filePath" as it does in the standard implementation of Okular, Poppler loads the file slowly like a snail over a high latency OpenVPN connection. It seems to seek itself to death. Even in a Gigabit Ethernet LAN over Samba it's noticable and users complain: "It can never reasonably take so long to display a 1..2 MB PDF file!" But if you let Qt read the file ("QByteArray fileContent = file.readAll();") and give Poppler the memory buffer (Poppler::Document::loadFromData), Okular displays the PDF file in fractions of a second as you would expect! Qt reads the file soo much faster than Poppler. That's why I always patch Okular and build it from source in our environment, as described here: https://bugs.kde.org/show_bug.cgi?id=507802#c5 But of course it would be better if Poppler would use an in-memory buffer instead of performing large quantities of seek operations on slow storage. That way it manages to be slow even for small files. Command line tools like pdftoppm are affected as well. -- You are receiving this mail because: You are watching all bug changes.
