Board.KolibriOS.org

Gluck
Вот оказывается как у Вас всё закручено - каждая точка имеет свои собственные поля формата координат (+4бита на каждую пару!!)
Но это не значит, что

если даже прямоугольник будет, его координаты (4 штуки) будут занимать от 4х до 8ми байт в зависимости от его положения внутри области.

Минимум 5 байт (4байта координат + 8бит полей размера), и то в самом лучшем случае, когда весь прямоугольник лежит внутри области 256х256.
Таких 5-байтовых прямоугольников будет 17% от всех возможных в квадрате 400х400.
Остальные кости упадут так: 6bytes - 38%; 7 - 32%; 8 - 12%; 9bytes - 1.7%

Для сравнения: в SWF-кодировке прямоугольник с 9-битными координатами в любом случае упаковывается в 5+4х9=41 бит

Теперь сравним оба метода на примере широкоформатной задачи: надо изобразить (допустим) карту звёздного неба - 20 тыс. пятнышек, разбросанных по простыне 16000х10000 пикселей, или 320,000х200,000 twips. У каждой звезды могут быть свой цвет, размер и форма, но нас интересует только кодирование их координат.

Сколько объектов попадет в квадрат 256х256 twips (2.5-байтовые координаты)? Ответ: НОЛЬ !
В полосах Х<65536 и Y<65536, находятся соответственно 20% и 33% всех звёзд, причем только 6% требуют 4.5-байтовой кодировки, остальные 49% занимают 6.5 байт. Ну и наконец 45% требуют 8 с половиной байт на пару.
ИТОГО: 142Кбайт для представления координат, из них 10000 байт используются только на кодирования размера данных.

SWF требует 5.125 байт (41 бит) на пару координат, или 100Кбайт на все объекты, при значительно более простом кодировании.

Извиняюсь за задержку.
Итак, поначалу пытался научиться рисовать в 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-редакторе.

konstantin_666 wrote:Не спешите. Парсер байт-кода - это такая штука, которую нельзя реализовать "неполностью".
Для реализации флэш необходимо добавить в библиотеку парсера абсолютно все объекты, которые описаны в спецификации.
Самый компактный парсер флэша весит 4 Мб. Библиотека векторных функций для флэша займёт гораздо больше, чем 4 Мб.
Не говоря уже о других библиотеках...

Я не знаю о каком байт коде говоришь ты, но в общем-то тебе уже ответили, читай спецификацию прежде чем что-то утверждать.
А сколько весит та операционная система, под которую написан (и скомпилирован) тот парсер флэша?

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

viewtopic.php?p=28821#p28821

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

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

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

Asper,

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

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

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

Пожалуйста. Интереснее всего было рисовать с помощью hex-редактора и калькулятора.

Gluk wrote:насчет ошибки - буду благодарен, если мне на нее укажут

Gluk wrote:[байт что рисовать - 1 круг, 2 прямоугольник, и т.д., или что объявить, 3 - градиент]

В байтовом же описании должно быть 1 прямоугольник, 2 круг, чтобы соответствовало словесному описанию. Потом совершенно непонятно, что представляют из себя параметры, ну ладно там цвет интуитивно понятно, но вот остальные можно было бы и поподробнее описать.

Asper, пример такой пример) список тэгов упорядоченный не создавался ни в каком виде пока что, список параметров каждого из них - тоже нигде не описан и не утвержден, в примере использовались примерные параметры, радиусы (второй радиус отсутствует, если бы присутствовал - это были бы эллипсы) и положения центров у кругов, размер у квадрата (был бы второй размер - был бы прямоугольник), ну и цвета

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

не в пересечении суть =) а в количестве объектов и их параметров, и как это будет выглядеть байткодово, и сколько займет объема, ну и, конечно как будет читаться парсерами

Тогда понятно.
Вобщем лично я готов работать над SWF. На разработку новых стандартов у меня попросту нет времени.

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-формат так же неудачен, как и для маленьких (иконки, графики, пиктограммы)

art_zh,
"так же неудачен, как и для маленьких" - а вот это что-то новенькое, есть аргументация? пока по объему я вижу у SWF проигрыш, по сложности - отсутствие выигрыша.
кстати, какое из утверждений верно, "SWF свободно масштабируем" или "1 твипс=1/20 пиксела"?
И разве свободно масштабируемый формат не лучше (гибче)?

Gluck

- а вот это что-то новенькое, есть аргументация? пока по объему я вижу у SWF проигрыш, по сложности - отсутствие выигрыша.

viewtopic.php?f=4&t=1489&start=72

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

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

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

art_zho,
"1-й пример (прямоугольник на малом поле): SWF-код компактнее в среднем на 25%," - там шла речь о способе задания координат. И во втором примере тоже. Ни капли не код компактнее, а координаты компактнее. В спецификации SWF идет пример с ОДНИМ объектом, на семьдесят с лишним байт. Я предложил пример с четыремя объектами на пятьдесят байт (даже с учетом сигнатуры в 3-4 байта в начале файла, и длины файла на столько же, будет менее 60 байт). Файл с одним объектом в моем варианте займет менее 22 байт, плюс только что описанный заголовок до 8 байт, итого 30 байт. И это несмотря на "плохой" способ задания координат, который кстати можно и изменить (формат то в разработке), только врядли на точно такой же как в SWF (софтверные патенты, и все такое)

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