Аналог gqview без gtk+?

Если я правильно тебя понял, Gwenview раньше такое умел. Сейчас не могу проверить, потому что загружаются и отображаются картинки мгновенно. Не смог повторить ситуацию, когда картинка не докачалась и нужно было бы её частично отрисовывать.

попробуй пихнуть ему какой-нибудь очбольшой жипег.
Это важно при просмотре фото с флешек и сетевых фс

а разве не все просмоторщики так делают? Наоборот загружать постепенно как браузер умеют не все. Сейчас глянул минималистичный qview он тоже долго ждет пока большая пикча загрузиться

Требование - отображать картинку до полной загрузки…

Во-первых, это зависит от самой картинки. Если картинка не сделана для прогрессивного отображения (гугли progressive jpeg или progressive png), то никто её не отобразит до полной загрузки.

…на адвайту пускай смотрят её разработчики, а не я.

Ну и смотри на пустой монитор.

Речь разумеется о картинках, умеющих это. gqview как-то справляется

да в том то и дело, что не могу найти софт, показывающий картинку прогрессивно кроме gqview и его убогого форка geeqie

Ну и смотри на пустой монитор.

я не запрещаю тебе смотреть на адвайту. Хоть распечатай и повесь её в рамочку. Но мне она нафиг не сдалась

Gwenview не показывает картинку, пока не загрузит полностью, проверил сейчас на всяких жирных 4k

ну да, даже на 4к это заметно, не говоря уже о том, что могут выдавать камеры

У меня таких, видимо, нет.

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

Я его раньше ставил и он не умел

Судя по треду, не хватает тега «тулкитофобия». А адвайта ужасна, но не настолько, чтобы из-за неё отказываться от использования полезного софта.

В любом случае даже если не бояться адвайты, держать gtk2/3 ради одного только просмотрщика картинок тоже не хочу. К тому же просмотрщик картинок всё-таки предпрлагает нормальный внешний вид.
Тег я бы может и добавил, но на лоре только 5 тегов можно.

Осмелюсь предложить свой вьювер Simple Viewer GL, поддерживает множество форматов, умеет смотреть картинки из сети (ждет их полной загрузки, но идея отображать картинку по мере загрузки мне понравилась, стоит добавить).

https://bitbucket.org/andreyu/simple-viewer-gl

Он подгоняет размер окна под размер картинки или наоборот - масштабирует картинку под размер окна?

Зависит от настройки.

Вьювер можно настроить из конфига, а можно хоткеем в рантайме.

Если не хочешь смотреть на «адвайту», попробуй Raleigh-Reliaded.

А потом после обновления gtk она отвалится...

feh

ок, как в нём включить отображение картинки сразу, а не только после полной загрузки?

Извини, обманул

Thu Aug  9 22:45:05 2001  Tom Gilbert  <gilbertt@linuxbrit.co.uk>

	* Progressive loading is gone. It's useless in imlib2 because
	imlib2 can't load from filehandles, it's real application is
	gone. Plus people say without seeing the image load it "feels"
	faster. This also simplifies a bunch of code and I feel cleaner
	without it.

geeqie совсем разваливается

он стал адово долго стартовать, но уже зависит от gtk3. Попробуй nomacs, но я пока не смог переехать полностью. Бесит в мелочах.

Ну, geeqie после переезда на Gtk3, емнип, стал долго стартовать. И да, это на nvme.

~# ldd /usr/bin/geeqie | wc -l
223

Жирненько. Тем не менее у меня за секунду стартует. Против feh это конечно долго, но не так чтобы слишком. Хорошо, что в слаке оно уже из коробки, а то я не стал бы устанавливать испугавшись зависимостей. К другим просмотрщикам так и не смог привыкнуть.

Если картинка не сделана для прогрессивного отображения (гугли progressive jpeg или progressive png), то никто её не отобразит до полной загрузки.

Это смотря что под этим понимать. progressive jpeg - это постепенная прорисовка с улучшением качества. А вот постепенная отрисовка части картинки сверху или снизу теоретически возможна для любых картинок.

Подскажи пожалуйста, чего ему не хватает? что за пакет такой?

-- Checking for module 'IlmBase'
--   Package 'IlmBase', required by 'virtual:world', not found

на сузе была ошибка

formats/xcf.cpp:565:21: Fehler: »numeric_limits« ist kein Element von »std«

но добавил #include <limits> и все скомпилилось. Надо бы добавить еще черный бэкграунд, а то самый темный это серый

Тем не менее у меня за секунду стартует.

нашёл причину, но не решение. Точнее так, это одна причина для:

1. незапусков и блока системы при попытке запустить wine, хоть в каком чистом профиле, достаточно только winecfg
2. лага с запуском qeeqie и прочих приложений, использующих clutter
3. банального запуска xrandr --listproviders - система на короткий момент блочится

болезнь, как я понимаю, характерная дл nVidia + intel гибридной графики и, скорее всего, косяков в драйвере nVidia для иксов.

Если запустить сессию в Wayland первые два пункта начинают отрабатывать на ура. Последний, по понятным причинам, самоустраняется. Появляются другие проблемы, правда.

Попытался включить nvidia_drm.modeset=1 - так иксы перестают грузиться с руганью от modeset(G0), что не может создать pixmap. Если же с этой опцией форсировать драйвер Xorg - nvidia, то поведение остаётся исходным: подвисания и фризы.

Это для нужно для поддержки формата OpenEXR. Если этот формат не интересен, то и либу устанавливать не обязательно.

Судя по сообщению, у вас какая-то часть либ установлена, поэтому система сборки считает поддержку этого формата обязательным.

Можно доустановить недостающие зависимости, можно удалить лишнее, можно отключить в cmakelists.txt поддержку этого формата.

Можно настроить в конфиге желаемый цвет.

Я так и не смог собрать 🤷‍♂️

Если из-за ошибке, что выше, то отключите поддержку этого формата в cmakelists.txt

А что за дистрибутив?

Дистрибутив Manjaro, собираю из AUR. Скорее всего, в pkgbuild что-то не так прописано, займусь попозже.

А, раскопал. Короче, это поведение появляется, когда для встроенной Intel используется драйвер modesetting. Если переключиться на intel, то всё становится отлично. Плюс glxgears, работающий на внешнем мониторе показывает 60fps, а под Wayland - 30, но там фактически, внешний монитор работает на 30FPS, вместо 60.

sxiv (nsxiv).

К слову, у тебя детект идёт через pkg-config, а более новые версии нативные модули для CMake предоставляют:

openexr /usr/lib/cmake/OpenEXR/
openexr /usr/lib/cmake/OpenEXR/OpenEXRConfig.cmake
openexr /usr/lib/cmake/OpenEXR/OpenEXRConfigVersion.cmake
openexr /usr/lib/cmake/OpenEXR/OpenEXRTargets-none.cmake
openexr /usr/lib/cmake/OpenEXR/OpenEXRTargets.cmake

Версия openexr: 3.1.9-1

Прошу прощения за некропостинг, сейчас снова поднял этот вопрос. Как выяснилось, из готовых загрузчиков изображений инкрементальная загрузка (но при этом без multiscan) сейчас реализована только в gdk-pixbuf. Даже в imlib2 не сделали, хотя там даже есть какая-то поддержка прогрессивной загрузки, но не инкрементальной. gqview даже динамически пытается подстраивать количество считываемых данных. Так же gqview передаёт в gdk-pixbuf размер желаемого изображения (jpeg умеет деноминаторы разрешения от 2 до 8)
При этом multi-scan mode я пока вообще нигде не видел из опенсорсного софта несмотря на то, что он реализован и дркументирован в libjpeg-turbo.
Интерфейс gdk-pixbuf оптимизирован для динамической загрузки и через коллбэки сообщает размер изображения (когда он становится известным) и новые порции картинки.
Как я понял, в simple-gl-viewer интерфейс загрузчиков изображений пока что инкрементальный режим не умеет. Есть ли смысл его дрбавлять? Это потребует переделать все декодеры.
Так же мне пока не совсем понятно, как лучше организовать декодирование в отдельном потоке. Очевидно, чтение может блокироваться и делать всё как в старых просмотрщиках в основном потоке - не самый эффективный способ. Но и обновлять кусок opengl текстуры из другого потока не совсем удобно - даже при использовании PBO делать TexSubImage будет основной.
Можно попытаться задействовать gbm или shared context, но возможно это будет что-то непортабельное

Как я понял, в simple-gl-viewer интерфейс загрузчиков изображений пока что инкрементальный режим не умеет. Есть ли смысл его дрбавлять? Это потребует переделать все декодеры.

Я не могу ответить на этот вопрос, т.к. не понимаю что означает «инкрементальный режим». Разве этот режим не предполагает поддержку со стороны кодека?

А в целом да, пришло время еще раз переписать вьювер с нуля. Мысли на этот счет есть, а времени нет.

Инкрементальный режим подразумевает дозагрузку изображения во время чтения файла. То есть в декодер передаётся не прочтитанный целиком буффер, а кусок, который успел прочитаться за небольшое время, и так повторяется, пока изображение полностью не загрузится. В gdk-pixbuf передали новую порцию данных, он обновил регион изображения. В этом действительно нет смысла в большинстве тулкитов, но в специальных просмотрщиках картинок, которые предполгают просмотр больших фотографий, способных грузиться хоть несколько секунд (например, с огромного архива на HDD).
Ещё есть progressive (multiscan) jpeg - это когда jpeg софрмирован так, что имеет первый слой пониженного качества и потом уже более качественный. В общем-то API для него получается такое же, как и для инкрементальной загрузки с одной лишь разницей, что один и тот же регион экрана может обновляться несколько раз.

Вот и получается, что для полноценной поддержки нужен соответствующий кодек. JPEG, gif, и еще какие-то старые форматы такую поддержку имеют.

Практически все raw и lossless форматы потенциально можно грузить инкрементально из-за последовательного сжатия. а в ходу для крупных фотографий как раз в основном только raw да jpeg

Вот это глянь. Хз есть ли там фичи о которых ты говоришь, но это один из самых быстрых просмотрщиков изображений, что я видел в Linux’ах:

https://github.com/woelper/oculante

oculante -- просмотрщик изображений с аппаратным ускорением

            let jpeg_data = std::fs::read(img_location)?;
            let buf: RgbImage = turbojpeg::decompress_image(&jpeg_data)?;
            let d = DynamicImage::ImageRgb8(buf);

            _ = sender.send(Frame::new_still(d.to_rgba8()));
            return Ok(receiver);

Нет, конечно же инкрементальной загрузки там нет, разве что покадровая загрузка анимаций