Медленная отрисовка PDF в okular

попробуй settings - configure - performance - memory usage

Выставил «максимальное использование», но лучше особо не стало(

Mupdf пробовал?

sumatrapdf?

mupdf?

Только что попробовал, работает как надо. И, судя по вентиляторам, работает благодаря видеокарте.

Не мануал Тенета смотришь?

Вот это тапок😲 Мне бы такой🤗

https://code-industry.net/free-pdf-editor/

А можно мне такой pdf-viewer, чтобы мог быстро искать. По работе приходится большой pdf регулярно грепать (8к страниц, TRM от техаса). Окуляр просто минутами ищет (буквально), щас по совету накатил mupdf. Заметно быстрей, но все еще бесяче-медленно. Хочется, чтоб прям сразу после энтора переходил на найденое.

у mutool есть ключики вытащить весь текст разом

дальнейшие грепы будут летат

грепы будут летат

Имелся ввиду поиск внутри смотрелки, а не греп по извлеченному тектстовому слою.

ну под офтопиком sumatra шустро ищет

а в чём проблема если файл тот же «проиндексировать» его один раз чем угодно что вытаскивает текст получить разбивку по страницам

и построить обратный индекс слово набор_страниц где это слово

?

и построить обратный индекс слово набор_страниц где это слово

Я про готовое решение, а не пердолинг. Чем пердолиться у меня есть.

можно взять туже суматру(либо mupdf) сырцы и подтюнить - будет быстрый поисковик - и даже можно(пердолинг ли это?) отмодифить pdf создав обратный индекс и добавить как в книгах :)

apvlv is a PDF/DJVU/EPUB/HTML/TXT/FB2/CZW viewer, which behaves like vim.
есть подозрение что это ${format}2txt со встроенным поиском через //n/p

Ну вот у меня zathura быстро ищет (к слову, онаа может использовать как бэкэнд poppler, так и mupdf). Но у меня какие-то жалкие полторы тыщи страниц, может этого мало для нормального теста.

Конечно можно, можно свой поисковик изобрести и свой просмоторщик. Но я ищу не это, а готовое подходящее решение. Его может и не быть, я уже большой, плакать не буду.

Даже mupdf это уже значительное улучшение! За него спасибо.

zathura + mudpdf, ИМХО, самый быстрый вариант.

А можно мне такой pdf-viewer, чтобы мог быстро искать.

qpdfview is a tabbed document viewer using Qt.
This version includes:

• PDF support using Poppler 24.02.0
• PS support using libspectre 0.2.12
• DjVu support using DjVuLibre 3.5.28
• Printing support using CUPS 2.4.7

А, ещё https://sioyek.info:

Sioyek is a PDF viewer designed for reading research papers and technical books.

В моем пакетном манагере внезапно есть Sioyek. Решил втянуть и посмотреть. Сразу видно маргинальную поделку. Пипецкое количество варнингов! Дальше будет жж:

1. Открыл свою мегадоку. открылась
2. показывает прогресс поиска в % - это жирный плюс! Весь документ просматривает за ~12 сек (так себе метрика, но мне бы хотелось 2-3сек).
3. Ввел в поиск фразу, которая точно есть в конце документа (скопипастил), он показал прогресс, дошел до 100% (пока все логично), потом вместо того, что бы показать найденное ушел в сегфолт.
4. Удалил

Продолжаю наблюдения:

qpdfview тоже есть в пакетах. Варнингов при сборке значительно меньше, но есть.

Поиск до конца документа прошел успешно. Всего за 22 сек. А при распараллеливании (есть такая опция поиска) - 9сек! И вот это уже заявка на рекорд!

Окуляр в похожей ситуации ищет минуту.

Спасибо за наводку.

Зато памяти будет жрать…

Попробуй xpdf.

Замечал такое, особенно на фоне всех мои малинок и прочего хлама. Atril чуточку быстрее, но чуточку. Всякие xpdf и прочие подобные - примерно так же, не слишком принципиально. Большие выигрыша достигается если оптимальней алгоритм быстрой выдачи именно нужной читаемой страницы, тут у окуляра тоже не очень - он кажется встаёт подожать пока дорисуется какая то предыдущая задача.

Виндовые и андроидовые .пдф-читалки явно быстрее на сопоставимом железе, практически любые. Что foxit, что ноунеймы найденые в f-droid. Хз почему, какой то огромной многопоточности я не замечал. Просто быстрее. Может там нет ускорения отрисовки на гпу?

Особняком от всех линуксовых идут встроенные в браузеры. Стоит попробовать, вдруг лучше к сценарию подойдёт? Ну или фоксит в вайн. Тоже может прокатить если там нет какого нибудь трэшинга системных вызовов или обращения к тормозному механизму обработки шрифтов.

И конкретно по окуляру - я обошёл проблему. Выставил экстримальное использование памяти в «производительности» и он теперь рисует всю книгу целиком и всё держит в памяти. zswap+ssd позволяет пропихнуть этого кита в форточку. Я просто открываю книжку и даю ей подгрузиться в фоне. За неимением другого решения оно наименее болезненно.

find ~/ -iname *okular* -delete

Особенно в ~/.local/share/okular/docdata/ вообще ад творится, регулярно нужно чистить от того, что не нужно. Там копятся настройки даже к тем книгам, которые давно уже удалены.

Выставил «максимальное использование», но лучше особо не стало(

Это выделение памяти, куда может быть загружена книга. Есть ещё прозрачность использования процессора. Возможно с диска или флешки книга не успевает подгружаться или обрабатываться процессором для отображения. К выделению памяти (8 гигов для книги, вы серьёзно?) не имеет отношения, достаточно дефолтных настроек.