Simple Viewer GL 3.3.1

Он все это делает дольше?

Это надо изучить. Ответ совершенно не очевден.

Тот случай, когда CPU новый, а GPU 15 лет на службе?

Наоборот, когда коре2 справляется лучше чем игровые видюхи Кризис+.

В любом случае, при чем тут мой вьювер?

Нужны тесты! Вдруг он даёт отрицательные улучшения?

Справедливости ради, сабж ничем не помог, скорость примерно та же что и у feh(который на CPU думаю).

Так там все упирается в декодирование. Если речь идет о каком-то стандартном формате типа jpeg/png, то скорость работы всех вьюверов будет +/- одинаковой.

Тут уже нужно выбирать, что больше подходит по фичам, юзабилити, интерфейсу. Мне нравится feh, но он до сих пор не умеет того, что нужно мне.

Аналогично - make deb валится из-за отсутствия version.h при том что саму версию определяет правильно. Странное.

Это надо изучить. Ответ совершенно не очевден.

Что мешает? :)

Наоборот, когда коре2 справляется лучше чем игровые видюхи Кризис+.

Уверен, что применить icc или сделать иное преобразование на CPU будет гораздо дольше. GPU будет делать это в рантайме без каких-либо лагов, а CPU будет крутить кулер несколько секунд.

Нужны тесты! Вдруг он даёт отрицательные улучшения?

Нужны - делайте. Для себя я тесты сделал давно, поэтому мой вьювер до сих пор развивается.

feh не просто цпу, он ещё и безнадёжно однопоточно.

Аналогично - make deb валится из-за отсутствия version.h при том что саму версию определяет правильно. Странное.

Это на свежесклонированном репозитории?

Аналогично

У меня была сколько-то летняя забытая копия, и после git pull проект не собрался.
Починилось выполнением git-clear из git-extras.

Если речь идет о каком-то стандартном формате типа jpeg/png, то скорость работы всех вьюверов будет +/- одинаковой.

А аппаратное декодирование фото/видео не задействуется? На каких то видеоускорителях видел подержку всяких jpeg и кучи других фотоформатов. И это даже отлично работало когда разбирал/собирал видео по кадрам.

безнадёжно однопоточно.

Разве он сам что-либо распаковывает? Он же использует внешние библиотеки для этого, а они, в свою очередь, могут быть многопоточными. Чтобы быть быстрым, feh не обязан сам быть многопоточным.

Что мешает? :)

Займусь! Но время... Думаю пару дней понадобится чтобы собрать и запустить.

Не помню ни одного многопоточного декодера фото. Я конечно больше половины из них не знаю, но самые распостранённые jpeg/png - однопоточные.

А аппаратное декодирование фото/видео не задействуется?

Декодирование на CPU, применение LUT на GPU. Или я не понял вопрос?

На каких то видеоускорителях видел подержку всяких jpeg и кучи других фотоформатов. И это даже отлично работало когда разбирал/собирал видео по кадрам.

Вполне возможно что есть и такое. А возможно, что в память видеокарты в потоке грузятся смежные кадры.

Большинство видеоредакторов использует прокси (встроенный, внешний), который просто выдает уменьшенные размеры кадров по запросу и эвристически набивает в потоке кеш кадрами, которые могут понадобиться редактору.

Не помню ни одного многопоточного декодера фото. Я конечно больше половины из них не знаю, но самые распостранённые jpeg/png - однопоточные.

А если использовать OpenCV для загрузки\декодирования картинки? Он вроде многопоточный всегда был.

Прямо даже интересно стало. Попробую этот png загрузить в imshow. Сколько займет интересно по времени.

Я конечно больше половины из них не знаю, но самые распостранённые jpeg/png - однопоточные.

Как минимум j2k умеет в многопоточность - opj_codec_set_threads(..., threads_count).

А libjpeg тормозной и однопоточный, libjpeg-turbo существенно шустрее как минимум за счет simd.

А если использовать OpenCV для загрузки\декодирования картинки? Он вроде многопоточный всегда был.

На «мелких» картинках смысла скорее всего нет, а на больших все упрется в скорость доступа к памяти. Но я не уверен, а проверить не смогу, т.к. явно не осилю написание декодера png/jpeg даже для CPU.

Но я не уверен, а проверить не смогу, т.к. явно не осилю написание декодера png/jpeg даже для CPU.

Так в opencv декодеры встроены. Просто вызов imread(если память не изменяет).

void 	cv::imread (const String &filename, OutputArray dst, int flags=IMREAD_COLOR_BGR)
 	Loads an image from a file.

Не, всё правильно понял.

Я именно что ffmpeg'ом раздёргивал видеопоток на кучу png/jpeg чтобы потом попиксельно сравнивать кадры. Так вот именно кодирование одной картинки было самой тяжёлой операцией, но аппаратный кодировщик сильно ускорял. Не помню, х86 или всё таки малина, а если малина то не помню, старый omx или новый mmal. А может я наобророт, собирал видео из кадров.

Не помню ни одного многопоточного декодера фото.

Из «свежих» – JPEG XL: https://libjxl.readthedocs.io/en/latest/api_threads.html.

Ага, помогло, мерси.

Нет, после git pull. Починилось удалением src/version.cpp - он в .gitignore поэтому git status показывал что всё ок. Понятия не имею почему он не пересоздавался при билде.

@IIIypuk, @dataman, @LINUX-ORG-RU, @Loki13 залил фиксы в master.

Надеюсь, все удалось пофиксить.

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

Починилось удалением src/version.cpp - он в .gitignore поэтому git status показывал что всё ок. Понятия не имею почему он не пересоздавался при билде.

Проблема в переезде со snake_case на CamelCase, а файл version.cpp был в .gitignore. Обновил игнор-лист.

Покидал в окно ещё разного мусора, не падает.

Ну и отлично, значит я корректно оценил проблему.

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

Теперь работает!

Под фряхой не билдится:

$ gmake release
...
-- Configuring done (3.3s)
-- Generating done (0.0s)
-- Build files have been written to: /home/iron/apps/simple-viewer-gl/.build_release
make[1]: option requires an argument -- j
usage: make [-BeikNnqrSstWwX]
            [-C directory] [-D variable] [-d flags] [-f makefile]
            [-I directory] [-J private] [-j max_jobs] [-m directory] [-T file]
            [-V variable] [-v variable] [variable=value] [target ...]
gmake: *** [Makefile:36: release] Ошибка 2

Чуток подправил Makefile:

--- Makefile.orig	2026-03-12 10:27:06.000000000 +0200
+++ Makefile	2026-03-12 10:27:26.000000000 +0200
@@ -40,7 +40,7 @@
 		-DAPP_VERSION_MAJOR:STRING=$(VER_MAJOR) \
 		-DAPP_VERSION_MINOR:STRING=$(VER_MINOR) \
 		-DAPP_VERSION_RELEASE:STRING=$(VER_RELEASE) && \
-		make -j
+		gmake -j
 	rm -fr $(OUT_NAME) && cp -r $(BUILD_DIR_RELEASE)/$(BUNDLE_NAME) $(OUT_NAME)
 
 .debug:

Автору хорошо бы пофиксить подобное. Либо докинуть BSDmakefile написанный для BSD make, либо это как-то разрулить в Makefile.

А вообще, програмуля понравилась. Если настрою хоткеи то наверно переползу на нее с imv.

Надеюсь, все удалось пофиксить.

Спасибо, теперь не падает.
Но многие svg неправильно показываются, например в smath_big.svg не показывается текст «SMATH».
Может быть, вместо NanoSvg использовать LunaSVG (PlutoVG 0.0.10 и LunaSVG 3.1.0)? Хотя она и намного больше.

Спасибо за отчет. Я подумаю, как это лучше пофиксить.

Верно, рендерингом занимается NanoSVG, вьювер лишь отображает результат.

Давно нужно было заняться улучшением рендеринга SVG, но это сложный формат и не хотелось тянуть во вьювер либу размером с пол браузера.

и не хотелось тянуть во вьювер либу размером с пол браузера

Ну, LunaSVG не очень большая. Например, в её примерах есть консольная утилита svg2png:

$ stat /usr/local/bin/svg2png
File: /usr/local/bin/svg2png
Size: 753232

$ ldd /usr/local/bin/svg2png
linux-vdso.so.1 (0x00007f039531c000)
libgtk3-nocsd.so.0 => /usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 (0x00007f0395222000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f0394e00000)
libm.so.6 => /usr/lib/x86_64-linux-gnu/libm.so.6 (0x00007f039512c000)
libgcc_s.so.1 => /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f03950fe000)
libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007f0394c0a000)
/lib64/ld-linux-x86-64.so.2 (0x00007f039531e000)

LunaSVG не очень большая.

Да, уже смотрю в ее сторону.

А утилита из LunaSVG корректно рендерит тот svg?

А утилита из LunaSVG корректно рендерит тот svg?

Да, svg2png конвертирует её правильно.

Ну и просто идея: в ImGUI же есть бэкенд SDL3, в которую добавили поддержку GPU.
Это, конечно, ещё одна зависимость, но возможно оно того стоит?
Ну и -gl придётся убрать из названия. :)

в ImGUI же есть бэкенд SDL3, в которую добавили поддержку GPU.

В моем случае, imgui - это лишь интерфейс попапов, а не оконная система.

Это, конечно, ещё одна зависимость, но возможно оно того стоит?

SDL3 - огромный комбайн, который под капотом все равно будет использовать OpenGL, D3D, Vulkan, вотэвер. Мне нужен кто-то, кто лишь создаст окно и контекст, предоставит инпут.

Что даст переход на SDL3 непонятно.

Ну и -gl придётся убрать из названия. :)

Очень давно вьювер был без GL в имени. Я давно хочу перейти на нативную оконную систему, чтобы избавиться от GLFW. И тогда под Linux будет OpenGL, под macOS будет Metal, под Windows будет D3D.

Но я никак не соберусь с силами чтобы завершить этот кусок работы.

ещё свой svg в imagemagick был вроде

консольная
gtk3

...

LunaSVG тоже норм. Несмотря на то, что он растеризует с premult alpha.

Зато благодаря этой странной фиче я немного пересмотрел реализацию рендерера и улучшил ее.

Первый набросок с использованием LunaSVG готов. Все оказалось гораздо проще.

Из плюсов:

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

Да я пробовал удалять gtk3-nocsd, но многие прежде собранные утилитки стали ругаться при запуске. Поэтому снова установил. :)

Разобрался, LunaSVG фолбэк делает на уровне фонта, а не глифа.

Если фонт загрузился, значит его используем. Если в нем нет нужного глифа, рисуем вместо него затычку, а не пытаемся найти глиф в других фонтах.

Плохо, но решить на стороне вьювера эту проблему не получится.

Как вариант, пропатчить LunaSVG. Но мне лень свои задачи решать, а уж браться за чужие тем более. Посему пока оставлю как есть, а как будет обновлен LunaSVG, обновится и вьювер.

Первый набросок с использованием LunaSVG готов.

Круто, спасибо! Хотя она оказалась и очень медленной.

Круто, спасибо! Хотя она оказалась и очень медленной.

Да, там есть что улучшать. Будем надеяться, что автор пофиксит и косяки, и поработает над оптимизацией.

Пока проект жив, такая надежда есть.

Да, там есть что улучшать.

Я бы и ThorVG 1.0 предложил, но она «тяжёлая». :)

Я бы и ThorVG 1.0 предложил, но она «тяжёлая». :)

А в описании легкая и шустрая. Хм.

Для поддержки Lottie в ней используется самсунговский JS-движок jerryscript.
Может и можно отключить поддержку Lottie, но я не вникал.

Для поддержки Lottie в ней используется самсунговский JS-движок jerryscript.

Не, хватит с меня. Я рад, что перешел на LunaSVG, но снова прыгать мне не хочется.

Сделал одну полезную фичу для svg (а потенциально для любых векторных форматов) - изменение масштаба картинки делает ее повторную пастеризацию с новыми значениями.

Как итог - картинка всегда гладкая вне зависимости от масштаба (с учетом клампа, естественно).

Я подумаю, как это лучше пофиксить.

Не использовать make -j, так как это полная дичь (и я прекрасно понимаю, почему бсдшники в своём make поддержали только форму с указанием числа процессов)

В данном случае нужно дёргать cmake --build вместо make

Круто, но на половину. Открывается также на втором (не основном для системы, в настройках HDMI монитор указан Primary) дисплее.

Я тут видосик записал (11 Mb, на фоне принтер печатает, сорри), посмотри.

Не использовать make -j, так как это полная дичь (и я прекрасно понимаю, почему бсдшники в своём make поддержали только форму с указанием числа процессов)

Почему -j без числа плохо?

Ага, спасибо. Посмотрю, что можно сделать.