Victor_VG
Tracker Mod | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
xanxan
Так в обоих ваших файлах как в формате DjVu находятся отсканированные картинки (для DjVu это предусмотрено спецификацией - в его контейнере находятся сжатые изображения и индексный блок указывающий порядок их чтения), а они декодируются видеоподсистемой. PDF по своей структуре это специальный вид текста описывающий как должна выглядеть страница на устройстве вывода - это набор команд разметки говорящий устройству что вывести в точке с заданными координатами который декодирует сама суматра, точнее движок MuPDF основанный на языке разметки Post Script (PS). И там могут встречаться изображения, но в PDF их мало, но основе PS/PDF лежат простые команды вида:
"В точке рабочего поля с координатами X,X вывести квадрат размером P на Q точек, залить его цветом ZZZZ и соединить его левый нижний угол нарисованного квадрата прямой цвета WWWWW с точкой с координатами J,,K ....".
А дальше видимая нами скорость отрисовки будет зависеть только от устройства вывода, а сама последовательность будет читаться с той скоростью, с какой это позволяет устройство где хранится PDF файл.
В случае с DjVu или если наш PDF содержит большое число картинок ситуация меняется - любая программа должна сначала извлечь изображение в ОЗУ, потом через ОС позвать его обработчик и дождаться пока тот её выведет, и только потом переходить к следующей.
И тут мы сталкиваемся с с тем, что чем больше размер картинки, тем дольше она читается и для её декодирования нужно больше ОЗУ, а для вывода на экран больше видеопамяти, точнее большие кадровый и рабочий буфера для построения экранной картинки в видеоадаптере. И вполне вероятно что в вашем случае узким местом становится именно он, особенно если машина использует встроенную графику не имеющую выделенной видеопамяти.
Картинка в контейнере может хранится как несжатом, так и в сжатом виде (для экономии места обычно её сжимают) и для её распаковки нам потребуется объём памяти равный её ширине умноженной на её высоту в пикселах умноженной на число цветовых каналов и умноженной на число байт на цвет. И для каждой картинки ещё понадобится место для хранения её сжатой формы и рабочая область для декодера. После декодирования ставшую ненужной память мы может использовать для других целей, но декодированная картинка нам будет ещё нужна и потому часть ОЗУ окажется занята. И так до его исчерпания. А чтобы этого не происходило ОС использует механизм страничного обмена списывая на диск редко или давно не используемые участки ОЗУ. А диск это Внешняя Память (ВП) ЭВМ - ёмкая, дешёвая но много более медленная чем ОЗУ, а значит эти операции потребуют времени, и чем их больше тем это заметнее - машина начинает считать дольше т.к. ей не хватает ОЗУ.
Думаю у вас проявляется именно этот набор явлений, а вы приняли его за медленную работу программы.
По вашим файлам - во первых большое спасибо за интересные исторические документы - с удовольствием прочитаю, такие вещи встречаются редко. Во вторых - эти документы по структуре похожи на DjVu (как я уже сказал в начале) и потому у вас декодируются медленно - тут просто "железка не тянет", отсюда все наблюдаемые вами явления.
У меня с момента отдачи ОС команды "Открыть документ с помощью сумары" до момента его отрисовки на экране для "Т 1 СБОРНИК СВЕДЕНИЙ О СЕВЕРНОМ КАВКАЗЕ (2).pdf" (58 Мб) по секундомеру прошло 1,58 сек, после чего никаких видимых задержек при прокрутке страниц как мышкой, так через PgUp/PgDwn или стрелки не наблюдается.
Правда машина значительно мощнее - процессор i7-2600 с 16 Gb ОЗУ, NVIDIA GTX 1060 и быстрыми серверными HDD. И по средствам контроля ОС видно что ситуации "не хватает памяти для обработки картинок" с этими файлами у меня нет, хотя сейчас ZxCAD обсчитывает достаточно сложную электронную схему, а винда со своими программами работает как прикладная задача в виртуалке под BSD UNIX что не прибавляет её шустрости.
Добавлено:
SumatraPDF v3.2 Git-e8102b92a
закоммитил.
----------
Жив курилка! (Р. Ролан, "Кола Брюньон")
Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti |
|
Всего записей: 33931 | Зарегистр. 31-07-2002 | Отправлено: 18:11 21-04-2019 | Исправлено: Victor_VG, 18:14 21-04-2019 |
|
) - эта программа довольно удобна и шустра, хотя то же не без недочётов, но думаю сможет выручить. Или XnViewMP + GhostScript - с ним он смотрит и PDF, а с картинками у него никогда проблем не было - это же его работа.