Board.KolibriOS.org

Official KolibriOS board
It is currently Wed Dec 02, 2020 3:27 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 144 posts ]  Go to page Previous 13 4 5 6 710 Next
Author Message
PostPosted: Sat Aug 21, 2010 5:06 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1439
Gluk wrote:
тогда предлагаю так изменить формат битфилда параметров: 0 - нет параметра этого. ну, на нет и суда нет. 1 - есть параметр, и следующие 2 бита означают длину параметра.
При этом если на 7м бите указывается единица параметра, то длина указана в первых двух битах следующего байта, 8й при этом выполняет роль 8го бита следующего байта битфилда, освобождая тот 8й бит от его специального значения.
Если на 6м бите указывается единица параметра, то следующие 2 бита показывают, сколько впереди еще битфилдов кроме одного (т.е. 00 если только один, 11 если 4), и тогда во всех остальных байтах битфилда, кроме 4го дополнительного (ну, если было 11, в послденем из них) 8й бит ничего не значит специального, и они обрабатываются как обычно.
Во всех остальных случаях 8й бит установлен в 1 если есть продолжение битмапа в следующем байте, в 0 - если битмап окончен, а во всех оставшихся параметрах, если таковые возможны, нули.

Честно говоря, ни фига не понял :(
По-моему, проще чем "у них" не придумаешь: если параметры занимают от 0 до 62 байт - на размер отводится 6 бит, а если от 63 до 4Гб - тогда 32 бита. Даже если попался незнакомый тэг, парсер всегда точно определит позицию следующего.


Quote:
-в предлагаемом формате размер _и_форма_ рисунка задается первым графическим объектом, который описан в файле, частота обновления не задается, так как не требуется для статики.
"Первый графический объект" в этом случае должен явно определять окно, иметь свой тэг, поле размера и 4 координаты. В SWF требуется только одна структура RECT

Quote:
"2) Код разбит на тэг-блоки. Тэг создает объект строго определенного класса, используя для этого параметры только своего блока, с адресацией данных относительно начала блока."
-не вижу что это дает

1) Отсутствие перекрестных связей на низшем уровне (на уровне тэгов такие связи есть и оформлены как отдельные тэги)
2) Возможность независимого парсинга каждого блока с линковкой в один проход

Quote:
-мой вариант без учета заголовка чуть ли не в два раза компактней будет, впрочем, дождемся результатов, обещанных Asper'ом

:!:
Quote:
-я в предыдущих постах двух предложил указывать размер данных в битовом поле, от 1 до 4 байт, или, в случае огромных полей для рисования, строкой координаты указать можно. А так до этого еще не дочитал)

Допустим, надо определить окружность (простейшая фигура!) в поле 400х400 единиц. При 2-байтном формате для ее описания требуется 6 байт; при битовом уплотнении - 4. Прямоугольник требует 2 пар координат: 8 байт или 6 байт при уплотнении. Треугольник: 3 пары координат (12 байт против 8 ) и т.д.


Last edited by art_zh on Sat Aug 21, 2010 5:38 pm, edited 1 time in total.

Top
   
PostPosted: Sat Aug 21, 2010 5:35 pm 
Offline
User avatar

Joined: Mon Apr 16, 2007 6:38 pm
Posts: 1222
art_zh, битфилды не только для этого. Они позволяют пропустить не только незнакомый тэг, но и незнакомый параметр. Они задают размер параметров, чтобы для координат, например, не использовать всегда 4 байта. И они показывают, какие параметры описаны (ведь они идентифицируются именно по их положению), а какие - нет. И все это плотно упаковано

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!


Top
   
PostPosted: Sat Aug 21, 2010 5:46 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1439
Gluk wrote:
art_zh, битфилды не только для этого. Они позволяют пропустить не только незнакомый тэг, но и незнакомый параметр. Они задают размер параметров, чтобы для координат, например, не использовать всегда 4 байта. И они показывают, какие параметры описаны (ведь они идентифицируются именно по их положению), а какие - нет. И все это плотно упаковано

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


Top
   
PostPosted: Sat Aug 21, 2010 6:02 pm 
Offline
User avatar

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

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!


Top
   
PostPosted: Sat Aug 21, 2010 6:33 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1439
Gluck
Такие случаи легко разрулить
а) по номеру версии (уж парсер-то знает когда какая фича была в нём реализована);
б) по фактическому размеру блока данных;
в) по дополнительным тэгам, в том числе и самодельным.
Ведь никто здесь не говорил, что векторный парсер обязан обрабатывать только какое-то определенное подмножество какого-то определенного стандарта, и больше ничего.


Top
   
PostPosted: Sat Aug 21, 2010 7:00 pm 
Offline
User avatar

Joined: Mon Apr 16, 2007 6:38 pm
Posts: 1222
art_zh,
замечу, что это я про свой черновик говорил (зачем еще битфилды, почему не тупо длина данных вместо них), а не про SWF (типа плохо что там такого нет. я такого не могу сказать даже по той причине, что не дочитал еще спецификацию по нему)
то есть я имел ввиду примерно следующее: "да, у них проще, но у меня на этом элементе помимо этой есть еще функциональность, потому усложнение оправданно"


Top
   
PostPosted: Sat Aug 21, 2010 10:18 pm 
Offline
User avatar

Joined: Mon Apr 16, 2007 6:38 pm
Posts: 1222
art_zh,
""Первый графический объект" в этом случае должен явно определять окно, иметь свой тэг, поле размера и 4 координаты. В SWF требуется только одна структура RECT"
для того чтобы быть первым графическим объектом, объект должен быть:
-объектом;
-графическим;
-первым(из графических объектов).
то есть это может быть розовый полупрозрачный круг с ободком в виде зеленых черточек толщиной в три пиксела и нулевой прозрачностью. И он при этом нарисуется. И объявит при этом поле рисунка, заодно. В SWF к кругу потребуется дополнительно еще и структура RECT.

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!


Top
   
PostPosted: Sun Aug 22, 2010 2:09 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1439
Gluk wrote:
... это может быть розовый полупрозрачный круг с ободком в виде зеленых черточек толщиной в три пиксела и нулевой прозрачностью. И он при этом нарисуется. И объявит при этом поле рисунка, заодно. В SWF к кругу потребуется дополнительно еще и структура RECT.

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

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

Конечно, я понимаю, этот самый первый тэг - он очень специальный, ради него вполне можно сделать исключение.
Только зачем?
Что мешает включить в заголовок компактную структуру RECT (минимум 2, максимум 17, реально 6-9 байт) и вообще забыть про "объект номер один"?


Top
   
PostPosted: Sun Aug 22, 2010 9:50 am 
Offline
User avatar

Joined: Mon Apr 16, 2007 6:38 pm
Posts: 1222
"Что мешает включить в заголовок компактную структуру RECT (минимум 2, максимум 17, реально 6-9 байт) и вообще забыть про "объект номер один"?"
ничто не мешает, но лишает возможности задания формы рисунка

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

"А что если юзер решит переместить фрейм на экране, изменить его размер? Что, парсер должен будет по ходу дела вносить исправления в параметры первого тэга?"
-если он захочет изменить размеры или положение фона относительно остальных объектов, таки да, придется вносить. Если нет - то ничего вносить не надо из изменений, внутри файла используются внутририсунковые координаты.

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!


Top
   
PostPosted: Sun Aug 22, 2010 10:53 am 
Offline
User avatar

Joined: Mon Apr 16, 2007 6:38 pm
Posts: 1222
art_zh,
"Допустим, надо определить окружность (простейшая фигура!) в поле 400х400 единиц. При 2-байтном формате..."
-стоп, я правильно понимаю что это окружность, занимающая все это поле? дыки тогда и радиус (200), и координаты центра (200,200) вполне умещаются в 1 байт каждый из размеров. Итого 3 байта против 4х?


Top
   
PostPosted: Sun Aug 22, 2010 11:49 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1439
Gluk wrote:
art_zh,
"Допустим, надо определить окружность (простейшая фигура!) в поле 400х400 единиц. При 2-байтном формате..."
-стоп, я правильно понимаю что это окружность, занимающая все это поле?

Нет, неправильно.
Я лишь привел примеры затрат на определение некоторых произвольных фигур в заданном координатном поле.
определить многоугольник = указать координаты всех его вершин;
для окружности - координаты центра и радиус;
для "горизонтального" прямоугольника (важный частный случай) - координаты противолежащих вершин.

Поле 400х400 выбрано в для сравнения двух методов представления координат.
В таком поле любой объект имеет только 9 значащих бит координаты. При Вашем способе кодирования для каждой координаты нужно отводить 16 бит, 7 из которых всегда будут нулями.
В SWF потребуется 9 бит на координату, плюс 5 бит на размер битового поля. Чем больше координат требуется для описания объекта, тем заметнее экономия места в параметрах тэга.


Top
   
PostPosted: Sun Aug 22, 2010 3:10 pm 
Offline
User avatar

Joined: Mon Apr 16, 2007 6:38 pm
Posts: 1222
"При Вашем способе кодирования для каждой координаты нужно отводить 16 бит, 7 из которых всегда будут нулями."
-вовсе не обязательно. я уже привел в пример окружность, для кодирования всех координат которой требуется 3 байта, по 8 бит на каждую. Также, если даже прямоугольник будет, его координаты (4 штуки) будут занимать от 4х до 8ми байт в зависимости от его положения внутри области. 14 бит будут излишними лишь для координат точек, находящихся в пределах поля, размером (400-256)х(400-256) точек. еще в одной области (256)х(400-256) будут лишними 7 бит (от одной координаты), и еще в одной (400-256)х(256) - 7 бит (от другой координаты), в области 256х256 лишних бит не будет по обеим. То есть уже не ВСЕГДА 14 бит нули, а в заметно менее половины случаев ((400-256)^2 меньше чем 256^2). Поясняю еще раз, для хранения размеров от нуля до 256 используется только один байт, и все. О каких двух байтах ВСЕГДА речь?


Top
   
PostPosted: Sun Aug 22, 2010 6:12 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1439
Gluck
Вот оказывается как у Вас всё закручено - каждая точка имеет свои собственные поля формата координат (+4бита на каждую пару!!)
Но это не значит, что
Quote:
если даже прямоугольник будет, его координаты (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Кбайт на все объекты, при значительно более простом кодировании.


Last edited by art_zh on Sun Aug 22, 2010 7:37 pm, edited 1 time in total.

Top
   
PostPosted: Sun Aug 22, 2010 7:15 pm 
Offline
User avatar

Joined: Fri Jun 27, 2008 3:22 pm
Posts: 988
Извиняюсь за задержку.
Итак, поначалу пытался научиться рисовать в 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 107 times
Top
   
PostPosted: Sun Aug 22, 2010 7:23 pm 
Offline
User avatar

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

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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 144 posts ]  Go to page Previous 13 4 5 6 710 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Limited