vitus_wagner (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
vitus_wagner) wrote2009-09-28 02:58 pm
vitus_wagner) wrote2009-09-28 02:58 pm
Entry tags:
Вьюеры картинок
Почему-то среди широко известных опенсурсных программ нет программы, которая бы позволяла просматривать БОЛЬШИЕ картинки. Под "большой картинкой" здесь понимается растровое изображение таких размеров, что его неупакованное 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 формат требуется больше места, чем у нас имеется в том, что на нашем девайсе заменяет жесткий диск.
no subject
no subject
А ведь память все кушать хотят -- у меня редко бывает больше 10М свободных.
no subject