Вьюеры картинок
Sep. 28th, 2009 02:58 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vitus_wagnerПочему-то среди широко известных опенсурсных программ нет программы, которая бы позволяла просматривать БОЛЬШИЕ картинки. Под "большой картинкой" здесь понимается растровое изображение таких размеров, что его неупакованное RGB-представление (обычно получается по 32 бита на пиксел, но достаточно и 24) не лезет в оперативную память.
То есть в resource-constrained environments вроде maemo "большой картинкой" будет уже лист А4, отсканированный на 600dpi. На десктопе с гигабайтом жизнь попроще. Но все равно есть вполне полезные вещи вроде graphviz, которые могут сгенерировать картинку, которая будет большой и для десктопа.
Задача, казалось бы элементарно простая - читаем картинку последовательно, пересчитываем координаты пикселов с учетом текущего размера окна, масштаба и выбранного viewport и заполняем offscreen pixmap размером с экран. На неё-то места хватит практически всегда. Это в DOS real mode на копию VESA-шного фреймбуфера в памяти места не хватало. И то вьюеры картинок под DOS писали и они работали.
Оказывается проблема в том, что у современного программиста даже не возникает мысль подойти к задаче системно. Вместо этого ищется готовый инструмент. На освоение которого уходит больше времени и сил, чем на написание вышеописанного простого алгоритма с нуля. Причем, желательно инструмент поуниверсальнее. Берем какой-нибудь GEGL и обнаруживаем что ему для загрузки картинки в свой tiled формат требуется больше места, чем у нас имеется в том, что на нашем девайсе заменяет жесткий диск.
То есть в resource-constrained environments вроде maemo "большой картинкой" будет уже лист А4, отсканированный на 600dpi. На десктопе с гигабайтом жизнь попроще. Но все равно есть вполне полезные вещи вроде graphviz, которые могут сгенерировать картинку, которая будет большой и для десктопа.
Задача, казалось бы элементарно простая - читаем картинку последовательно, пересчитываем координаты пикселов с учетом текущего размера окна, масштаба и выбранного viewport и заполняем offscreen pixmap размером с экран. На неё-то места хватит практически всегда. Это в DOS real mode на копию VESA-шного фреймбуфера в памяти места не хватало. И то вьюеры картинок под DOS писали и они работали.
Оказывается проблема в том, что у современного программиста даже не возникает мысль подойти к задаче системно. Вместо этого ищется готовый инструмент. На освоение которого уходит больше времени и сил, чем на написание вышеописанного простого алгоритма с нуля. Причем, желательно инструмент поуниверсальнее. Берем какой-нибудь GEGL и обнаруживаем что ему для загрузки картинки в свой tiled формат требуется больше места, чем у нас имеется в том, что на нашем девайсе заменяет жесткий диск.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2009-09-30 10:39 am (UTC)Спрашивали его о размере в пикселях, отвечает в мегабайтах неизвестного формата...
"Смириться с тормозами" -- это выход.
Но если вариант требующий написания большего куска кода в 99% случаев не имеет преимуществ, то скорее всего он будет отклонен.
Пока 99% входят в память, никто не будет даже думать о чтении картинки по частям.
Пока нам хватало 2 ГБ адресного пространства, я не парился с собственным свопом, полагаясь на системный. Но пришлось :)