формат векторной графики

Applications development, KoOS API questions
  • User avatar
    Asper
    Posts 988
    Joined: Fri Jun 27, 2008 3:22 pm

    Извиняюсь за задержку.
    Итак, поначалу пытался научиться рисовать в hex-редакторе, но надоело высчитывать битовые поля потому нарисовал в нем только квадрат 400x400 c толщиной границы в 5 пикселов (100 твипов) и прозрачностью границы 0.7 во фрейме тоже размером 400x400.
    Потом взял Macromedia MX 6.0 и нарисовал всю картинку в нем по твоему словесному описанию насколько я это понял. (Кстати в байтовой кодировке этой картинки в твоем формате то ли у тебя ошибки, то ли я чего не так понял).

    Полученный файл занимает в общем 302 байта, из них 20 байт в начале файла заголовок SWF.
    Кроме того судя по всему в выходном файле ещё оказалась куча мусора (одинаковые стили линий и неиспользуемые стили линий и заливок), то ли вследствии того, что я несколько раз перерисовывал картинку пока получил нужный результат, то ли из-за старой версии SWF редактора (не зря же существует оптимизаторы флэш файлов).

    Вобщем вот сам файл (1mn.swf), файл проекта (1.fla), дефлэш лог fltk-gnash (1mn.log), моё подробное описание дампа файла 1mn.swf (1mn bits desc.txt), правда не до конца, там уже думаю по спецификации разберёшься. Также в папке first то, что я нарисовал в hex-редакторе.
    Attachments
    1.7z (5.52 KiB)
    Downloaded 229 times
  • User avatar
    Asper
    Posts 988
    Joined: Fri Jun 27, 2008 3:22 pm

    konstantin_666 wrote:Не спешите. Парсер байт-кода - это такая штука, которую нельзя реализовать "неполностью".
    Для реализации флэш необходимо добавить в библиотеку парсера абсолютно все объекты, которые описаны в спецификации.
    Самый компактный парсер флэша весит 4 Мб. Библиотека векторных функций для флэша займёт гораздо больше, чем 4 Мб.
    Не говоря уже о других библиотеках...
    Я не знаю о каком байт коде говоришь ты, но в общем-то тебе уже ответили, читай спецификацию прежде чем что-то утверждать.
    А сколько весит та операционная система, под которую написан (и скомпилирован) тот парсер флэша?
  • User avatar
    Asper
    Posts 988
    Joined: Fri Jun 27, 2008 3:22 pm

    Добавил описание общего парсинга swf файлов в Kofee. Файл обрабатывается полностью при этом незнакомые теги пропускаются, а на знакомые вызывается функция-обработчик тега, которая производит последующий парсинг этого тега и выполняет всю необходимую работу связанную с данным тегом. В принципе доработка Kofee состоит в том, чтобы добавлять отсутсвующие обработчики тегов, а также сделать нормальные Dictionary и DisplayList.

    viewtopic.php?p=28821#p28821
  • User avatar
    Gluk
    Posts 1222
    Joined: Mon Apr 16, 2007 6:38 pm

    art_zh,
    Ну, в таких областях как картография, звездная картография, это так. Для таких случаев формат координат формата SWF действительно экономичней формата координат в моем варианте. (я не говорю что SWF в данной ситуации экономичней моего формата, это надо изучать детальнее, и нужно больше проработать формат, чтобы избавиться от "белых пятен", и спецификацию SWF таки дочитать, ну и, возможно, реализовать оба варианта в файлах (звезды теми же кружками реализовав))

    Однако самое большое поле для рисования в КоОС, как мне видится, это рабочий стол, ну 2k*1,8k пикселов, и с десяток-другой объектов. Здесь разница не будет столь существенной. Уж иконки рабочего стола-то врядли будут больше чем 256*256 каждая, однако и для бОльших размеров все будет работать, правда, с дополнительным байтом кое-где. Виджеты - ну 256*2k максимум, опять же, и те же десятки объектов.

    Кстати, для картографии этот формат не подойдет еще и по той же причине, как и его прообраз (SVG): для правильного отображения участка изображения следует загрузить все изображение (в т.ч. в память).

    Asper,

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

    "Кстати в байтовой кодировке этой картинки в твоем формате то ли у тебя ошибки, то ли я чего не так понял" - ошибки не исключены, более того, пример больше не соответствует черновику спецификации ввиду изменения в черновике формата битовых полей параметров. Однако в резервные 50 байт он таки все равно уместится если его подправить) а насчет ошибки - буду благодарен, если мне на нее укажут)

    "не зря же существует оптимизаторы флэш файлов"
    -было бы здорово, если бы кто-нибудь пропустил этот файл (не на замену, а в копию) через такой оптимизатор, очень жалею что лишен пока что возможности сделать это самостоятельно..
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • User avatar
    Asper
    Posts 988
    Joined: Fri Jun 27, 2008 3:22 pm

    Пожалуйста. Интереснее всего было рисовать с помощью hex-редактора и калькулятора. :)
    Gluk wrote:насчет ошибки - буду благодарен, если мне на нее укажут
    Gluk wrote:[байт что рисовать - 1 круг, 2 прямоугольник, и т.д., или что объявить, 3 - градиент]
    В байтовом же описании должно быть 1 прямоугольник, 2 круг, чтобы соответствовало словесному описанию. Потом совершенно непонятно, что представляют из себя параметры, ну ладно там цвет интуитивно понятно, но вот остальные можно было бы и поподробнее описать.
  • User avatar
    Gluk
    Posts 1222
    Joined: Mon Apr 16, 2007 6:38 pm

    Asper, пример такой пример) список тэгов упорядоченный не создавался ни в каком виде пока что, список параметров каждого из них - тоже нигде не описан и не утвержден, в примере использовались примерные параметры, радиусы (второй радиус отсутствует, если бы присутствовал - это были бы эллипсы) и положения центров у кругов, размер у квадрата (был бы второй размер - был бы прямоугольник), ну и цвета
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • User avatar
    Asper
    Posts 988
    Joined: Fri Jun 27, 2008 3:22 pm

    Оно понятно, что пример абстрактный. Но как понять какое число, что значит. Вот я не мог понять пересекаются окружности из примера или нет, потому как не знал, где там координаты центра, величина радиуса и вообще, эти ли параметры используются или, что другое. Потому сделал на своё усмотрение не пересекающимися, со своими координатами.
  • User avatar
    Gluk
    Posts 1222
    Joined: Mon Apr 16, 2007 6:38 pm

    не в пересечении суть =) а в количестве объектов и их параметров, и как это будет выглядеть байткодово, и сколько займет объема, ну и, конечно как будет читаться парсерами
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • User avatar
    Asper
    Posts 988
    Joined: Fri Jun 27, 2008 3:22 pm

    Тогда понятно.
    Вобщем лично я готов работать над SWF. На разработку новых стандартов у меня попросту нет времени.
  • User avatar
    art_zh Kernel Developer
    Posts 1465
    Joined: Fri Aug 14, 2009 1:46 am

    Gluk wrote:art_zh,
    Ну, в таких областях как картография, звездная картография, это так. Для таких случаев формат координат формата SWF действительно экономичней формата координат в моем варианте. (я не говорю что SWF в данной ситуации экономичней моего формата, это надо изучать детальнее, и нужно больше проработать формат, чтобы избавиться от "белых пятен", и спецификацию SWF таки дочитать, ну и, возможно, реализовать оба варианта в файлах (звезды теми же кружками реализовав))

    Однако самое большое поле для рисования в КоОС, как мне видится, это рабочий стол, ну 2k*1,8k пикселов, и с десяток-другой объектов. Здесь разница не будет столь существенной. Уж иконки рабочего стола-то врядли будут больше чем 256*256 каждая, однако и для бОльших размеров все будет работать, правда, с дополнительным байтом кое-где. Виджеты - ну 256*2k максимум, опять же, и те же десятки объектов.

    Кстати, для картографии этот формат не подойдет еще и по той же причине, как и его прообраз (SVG): для правильного отображения участка изображения следует загрузить все изображение (в т.ч. в память).
    1) 2k пикселей - это 40 тыс. твипсов. Реальный векторный объект (например, страница текста с TTF-шрифтами) вполне может иметь полмиллиона твипсов в длину и столько же - ширину.
    Что же касается предыдущего примера, то 400х400 твипс соответствовал размеру небольшой иконки (20х20 pix)

    2) загрузить 100кбайт в память - это проблема? (это классическая векторная задача, растровой графике такие задачи вообще не по зубам). Проблема - все это быстро и просто обработать

    3) я лишь показал, что для больших векторных файлов (карты, чертежи, длинные многошрифтовые тексты) Gluk-формат так же неудачен, как и для маленьких (иконки, графики, пиктограммы)
  • User avatar
    Gluk
    Posts 1222
    Joined: Mon Apr 16, 2007 6:38 pm

    art_zh,
    "так же неудачен, как и для маленьких" - а вот это что-то новенькое, есть аргументация? пока по объему я вижу у SWF проигрыш, по сложности - отсутствие выигрыша.
    кстати, какое из утверждений верно, "SWF свободно масштабируем" или "1 твипс=1/20 пиксела"?
    И разве свободно масштабируемый формат не лучше (гибче)?
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • User avatar
    art_zh Kernel Developer
    Posts 1465
    Joined: Fri Aug 14, 2009 1:46 am

    Gluck
    - а вот это что-то новенькое, есть аргументация? пока по объему я вижу у SWF проигрыш, по сложности - отсутствие выигрыша.
    viewtopic.php?f=4&t=1489&start=72

    1-й пример (прямоугольник на малом поле): SWF-код компактнее в среднем на 25%,

    2-й (много отдельных точек на широком поле) - на 40%.

    Можно привести и другие примеры, только зачем - Вы их все равно не читаете, а другим все и так ясно.
    Лучше было внять совету мудрого Mario и не затевать пустопорожних дискуссий.
    Евангелие от Иоанна: стих 1

    Code: Select all

    ; В начале было Слово:
B32:        mov     ax, os_stack       ; Selector for os
    [/size]
  • User avatar
    Gluk
    Posts 1222
    Joined: Mon Apr 16, 2007 6:38 pm

    art_zho,
    "1-й пример (прямоугольник на малом поле): SWF-код компактнее в среднем на 25%," - там шла речь о способе задания координат. И во втором примере тоже. Ни капли не код компактнее, а координаты компактнее. В спецификации SWF идет пример с ОДНИМ объектом, на семьдесят с лишним байт. Я предложил пример с четыремя объектами на пятьдесят байт (даже с учетом сигнатуры в 3-4 байта в начале файла, и длины файла на столько же, будет менее 60 байт). Файл с одним объектом в моем варианте займет менее 22 байт, плюс только что описанный заголовок до 8 байт, итого 30 байт. И это несмотря на "плохой" способ задания координат, который кстати можно и изменить (формат то в разработке), только врядли на точно такой же как в SWF (софтверные патенты, и все такое)
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • User avatar
    Gluk
    Posts 1222
    Joined: Mon Apr 16, 2007 6:38 pm

    Asper, еще раз спасибо, я сделаю в своих проектах поддержку формата SWF если Колибри-реализация его будет достаточно развита на тот момент (и не будет слишком "тяжелой").
    Свой формат буду доделывать, так как я уже потратил на него больше времени чем планировал. Придумал еще интересные вещи, опубликую с первой версией формата (в которой хотя бы самые базовые элементы и свойства будут описаны). Некоторые из них, надеюсь, будут довольно интересны, однако дальнейшего усложнения формата не планируется (по крайней мере такого уровня, какого произошли с битовыми полями). И да, код реализации by me таки будет, но после публикации и обсуждения спецификации, по несколько раз переделывать его не очень хочется. Да и время надо будет найти.
    Таки еще предложения по форматам приветствуются (доработка моего варианта/другие варианты).
    • Post Reply

    Return to “Coding”

    Who is online

    Users browsing this forum: No registered users and 5 guests