Simple Viewer GL 3.3.1

v3.3.1

А CMake пишет:

****************************************
*           Simple Viewer GL           *
*                v1.0.0                *
****************************************

Кому верить? :)

Ещё и ругается:

simple-viewer-gl/src/version.cpp:10:10: fatal error: version.h: No such file or directory
   10 | #include <version.h>
      |          ^~~~~~~~~~~
compilation terminated.

****************************************
*           Simple Viewer GL           *
*                v3.3.1                *
****************************************
*            Release Build             *
****************************************

Собирал через make release, как указано в инструкции

Собирал через make release

А я c cmake -G Ninja -B build.

как указано в инструкции

Так собралось. :)

Какие-то флюиды, не иначе. Теперь с Ninja тоже собралось.

У меня падает при попытке использовать полноэкранный режим:

Thread 1 "sviewgl" received signal SIGSEGV, Segmentation fault.
0x00007ffff7cbcff4 in Xutf8LookupString () from /usr/lib64/libX11.so.6
(gdb) bt
#0  0x00007ffff7cbcff4 in Xutf8LookupString () from /usr/lib64/libX11.so.6
#1  0x00007ffff7e775ad in ?? () from /usr/lib64/libglfw.so.3
#2  0x000055555562355d in cWindow::pollEvents (this=0x7fffffffd340) at /home/ktokarev/src/git/simple-viewer-gl/src/Window.cpp:401
#3  0x000055555562563c in main (argc=2, argv=0x7fffffffd8a8) at /home/ktokarev/src/git/simple-viewer-gl/src/main.cpp:296
(gdb) 

У меня не падает, но открывает полновэкранный режим на основном мониторе, а не на котором было окно (по возвращении в оконный режим остаётся на основном экране).

UPD:

libX11.so.6

WM: KWin (Wayland)

Хм, и скобки вместо кавычек, и v вместо V.

Странно.

Что за видео драйвер / карта?

Спасибо, изучу в ближайшее время.

NVidia 580.126.09 / GT1030, WM Awesome

Странно.

Да не, это у меня что-то с копией случилось. После git-clear всё нормально.

Что за видео драйвер / карта?

У меня тоже падает после нажатия Enter. NVIDIA GeForce GTX 1050 Mobile / 550.163.01-4 / KDE Plasma 6.5.4 (X11).

просмотр картинки через опенгл. это прямо какой-то новый уровень извращений.

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

Тема Ленки не раскрыта.

А у тебя какое DE и оконный менеджер? Если гном, кеды или типа того с композитором (не чисто программным), то всё что ты видишь на экране это OpenGL, через Clutter, Cogl.

Наверняка что-нибудь отломал, поэтому буду рад замечаниям и советам.

Собрал просто как make

****************************************
*           Simple Viewer GL           *
*                v3.3.1                *
****************************************
*            Release Build             *
****************************************
* [+] OpenGL found                     *
* [+] GLFW3 found                      *
* [+] Threads found                    *
* [+] X11 found                        *
* [+] ZLib found                       *
* [+] PNG support enabled              *
* [+] JPEG support enabled             *
* [ ] EXIF support dropped             *
* [+] LCMS2 support enabled            *
* [ ] OpenJPEG2 support dropped        *
* [+] GIF support enabled              *
* [+] TIFF support enabled             *
* [+] WebP support enabled             *
* [ ] OpenEXR support dropped          *
* [+] Curl support enabled             *
* [ ] HEIF support dropped             *
****************************************
-- Configuring done (18.3s)
-- Generating done (0.2s)

Запустил из каталога сборки ./sviewgl, поперетягивал картинки мышкой, работает, перетянул каталог с картинками, работает. Перетянул каталог ~/Загрузки с разным мусором, без картинок.

dron@gnu:~/Рабочий-стол/simple-viewer-gl$ ./sviewgl 
Using default config.
terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string: construction from null is not valid
Аварийный останов      ./sviewgl
dron@gnu:~/Рабочий-стол/simple-viewer-gl$ 

размер в памяти (CPU + GPU)

Прикольно. А использование Ram/Vram не показывает?

одноконный

С одним конём? )

Потому что незачем тратить драгоценное время процессора на просмотр фоток с летних шашлыков. Ему и без этого есть чем заняться.

Поправил.

Как раз процессору быстрее самому просмотреть фотку чем строчить openGL-вызовы для отрисовки джипега на видеокарте. Возможно когда размер холста переваливает за 100Мпикс что то и меняется, но это к счастью весьма редкий сценарий.

https://i.imgur.com/O4GR8PQ.png

1. Сверху сабж, снизу feh. Если приблизить и присмотреться, то в отличии от feh, присутствует какая-то пикселизация на границе объекта(да и не только на границе).

2. Понажимал много раз на Enter и получил

Upd: Уточнение, падает если нажать Enter и не отпускать. Падает после 2го переключения.

sviewgl: /var/tmp/portage/media-libs/glfw-3.4/work/glfw-3.4/src/input.c:274: _glfwInputKey: Проверочное утверждение «window != NULL» не выполнено.
fish: Job 1, './sviewgl ~/Pictures/' terminated by signal SIGABRT (Abort)

Также если нажать Enter подряд много раз, то переключение происходит ещё несколько секунд. Может промежуточные переключения туда-сюда стоит скипать?

3. Ожидал по PgUp\PgDown перехода к следующей\предыдущей картинке в каталоге, но не сработало, переключило на пустую.

Мне кажется это из-за энергосбережения на ноутах, там выводить процессор из спячки намного дороже по аккуму, чем сделать всё это на GPU.

Спасибо.

Для создания окна и контекста используется GLFW. Или я не умею его готовить, или что-то с ним не так, но для переключения режима мне когда-то пришлось делать костыли.

Частично костыли делались для поддержки тайловых оконных менеджеров, включая hyprland.

Возможно, это повод перейти на наливную реализацию. Но очень не хочется заниматься инициализацией контекста, обработки инпута, drag-n-drop и клипбордом врукопашную. Но намек я понял, спасибо.

просмотр картинки через опенгл. это прямо какой-то новый уровень извращений.

Ага, у меня же есть CPU, зачем мне использовать GPU.

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

А можно в контексте вьювера пояснить, что стало медленнее после переноса вычислений на GPU?

Я вижу лишь ускорение. Тот же LUT (ICC) на CPU на моих тестовых образцах выполнялся 10+ секунд, а теперь это делается на GPU.

Спасибо, похоже что в fmtlib прилетело что-то неперевариваемое. Разберемся.

Прикольно. А использование Ram/Vram не показывает?

Только сумма. Есть смысл разделить?

С одним конём? )

Кони нынче дорогие, хватило только на одного :)

Только сумма. Есть смысл разделить?

Нет разумеется, как и в сумме. У подавляющего большинства пользователей просто нет и никогда не будет изображений для которых это имеет значение. Но всё-равно прикольно, поэтому можно и разделить :)

Было бы прикольно.

У вас походу глаз замылился:

размер в памяти (CPU + GPU)

У них вся память - это кэш l1, l2 и тд. Осмелюсь предположить, что имели в виду ram/vram 🐱

Там там же двойная петля получается, цпу-гпу-цпу-гпу. Что что, а спать он точно не будет ни при каких условиях. Даже если удастся сделать zero copy - всё равно надо проснуться и много раз обменяться вызовами между приложением, ядром и видеокартой.

Уже многократно проверено - простые короткие задачи ускоряются именно отключением аппаратного ускорения если у тебя есть хотя бы коре2. ДАже на Распбри Пи 4 (кортекс-а72) это не так уж очевидно кто быстрее. Другое дело если вебЖЛ со сценой на тысячи полигонов, какй нибудь новый 2ГИС. Но тут то один!

Это надо изучать алгоритмы декодирования и обработки изображений. Возможно вот эти управляющие команды можно на одном медленном ядре делать не пробуждая все, а если будешь декодировать и обрабатывать, то пробуждай всю печку. Но опять же, без тестов(10000 картинок на CPU и 10000 картинок на GPU) я бы не брался утверждать что больше сожрет батареи. ТС вон говорит что какие-то алгоритмы у него получились на GPU в 10 раз быстрее(10 сек на процессоре было).

Уже многократно проверено - простые короткие задачи

Картинка с зеркалки на кучу мегапикселей, это простая задача? Она у меня отрисовывается прямо видно глазами что не мгновенно и когда переключаешь их одну за одной это некомфортно и хочется ускорить. И это 12 ядерный проц десктопный. IO мало вероятно что виновато, там NVME шустрый.

1. Сверху сабж, снизу feh. Если приблизить и присмотреться, то в отличии от feh, присутствует какая-то пикселизация на границе объекта(да и не только на границе).

FEH мылит?

2. Понажимал много раз на Enter и получил

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

3. Ожидал по PgUp\PgDown перехода к следующей\предыдущей картинке в каталоге, но не сработало, переключило на пустую.

Регрессия. Заметил баг не сразу, поэтому отложил его починку на следующий раз.

открывает полновэкранный режим на основном мониторе, а не на котором было окно (по возвращении в оконный режим остаётся на основном экране).

Пофиксил. Сегодня залью разом все фиксы.

FEH мылит?

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

Это вьювер или професиональный цветокоректор? От вьювера с simple в названии ждёшь скорее что он запустится быстрее feh, нарисует картинку в окне так быстро как только возможно сделать декодирование ну и мгновенной реакции и отсутствие лагов при масштабировании и например перемещении. Так что я имею в виду общий принцип - не надо тянуть на ГПУ всё с чем ЦПУ и так справялется быстрее 50мс даже если ему 15 лет. Вот внедрили тотальный openGL в интерфейсы - теперь анимации в qt5/6/гтк3+ начали подлагивать. Внедрили в веб - тот же 2Гис стал тормозным, хотя рисует всё то же самое пиксель в пиксель.

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

Было бы здорово узнать результаты сравнения.

Есть какой эталонный просмотрщик?

Может браузер при 100% зуме?

А зачем там libcurl? Что просмотрщик картинок делает с сетью?

Это вьювер или професиональный цветокоректор?

Он ничего не корректирует, а лишь старается отобразить корректно изображение. На мой взгляд, это основная фича вьювера.

От вьювера с simple в названии ждёшь скорее что он запустится быстрее feh, нарисует картинку в окне так быстро как только возможно сделать декодирование ну и мгновенной реакции и отсутствие лагов при масштабировании и например перемещении.

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

Так что я имею в виду общий принцип - не надо тянуть на ГПУ всё с чем ЦПУ и так справялется быстрее 50мс даже если ему 15 лет.

Я не слышал про этот «общий» принцип. В любом случае, считаю странной претензию к вьюверу из-за использования GPU для вывода картинки.

Вот внедрили тотальный openGL в интерфейсы - теперь анимации в qt5/6/гтк3+ начали подлагивать.

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

У меня какая-то старая Nvidia, но лагов анимации в Hyprland не вижу.

Внедрили в веб - тот же 2Гис стал тормозным, хотя рисует всё то же самое пиксель в пиксель.

Я не пользуюсь 2Гис напостоянку, но не помню, чтобы мог назвать его шустрым. В любом случае, при чем тут мой вьювер?

Было бы здорово узнать результаты сравнения.

В gwenview как у тебя, в showfoto(который часть Digikam) как в feh. Так что 1-1 пока что(ну или 2-2).

Пикселят: simpleviewer, showfoto, kolourpaint, krita

Мажут: feh, gwenview, firefox, vivaldi, qutebrowser, imv, swayimg

Что смог - потестировал.

А зачем там libcurl? Что просмотрщик картинок делает с сетью?

Умеет тянуть картинку по сети. Было время, когда мне нужно было смотреть картинки, на которые мне присылали ссылки. Надоело их скачивать, смотреть, удалять. Поэтому и добавил такую функциональность.

С помощью CURL он качает картинку во временную директорию, показывает ее, а картинку удаляет.

Если фича не нужна, то можно запретить ее с помощью DISABLE_CURL_SUPPORT.

Картинка с зеркалки на кучу мегапикселей, это простая задача?

Да не то чтобы сложная. Пи3/кортекс-А53 feh 1 ядро 2 секунды, причём через vnc, а на пи4/кортекс-а72 - полсекунды. Кэнон 24Мписк. В обоих случаях я не уверен что задействованы инструкции neon (+30-100%).

С другой стороны вращение уже целых 3 секунды, а видеокарта должна была бы сделать почти мгновенно.

Что смог - потестировал.

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

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

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

Осмелюсь предположить, что имели в виду ram/vram 🐱

Все верно.

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

Не за что. В идеале, кмк, настройку бы добавить сглаживать или нет. Для просмотра фото, сглаживание предпочтительнее выглядит. Для работы - согласен, без сглаживания правильнее.

а видеокарта должна была бы сделать почти мгновенно.

Видеокарте вообще все равно, где будет расположен вертекс. Так что вращения и флипы на GPU бесплатные.

Можно попробовать сделать шейдер, который регулирует сглаживание. Закину ее в список задач, но когда за нее возьмусь не знаю.

Я только что проверил на 12 ядерном 3900X картинку png 600dpi, 9910x7016 в пикселях. Отрисовывает секунду примерно. Когда таких картинок много и по ним надо ходить, это больно. Справедливости ради, сабж ничем не помог, скорость примерно та же что и у feh(который на CPU думаю).