Board.KolibriOS.org

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

All times are UTC+03:00




Post new topic  Reply to topic  [ 144 posts ]  Go to page Previous 1 2 3 4 510 Next
Author Message
PostPosted: Thu Aug 19, 2010 8:43 pm 
Offline
User avatar

Joined: Fri Jun 27, 2008 3:22 pm
Posts: 988
Люди, если не лень почитайте спецификацию на SWF, всё, что вы предлагаете там уже есть. А после прочтения у вас ещё и новые мысли появятся на эту тему. :)


Top
   
PostPosted: Thu Aug 19, 2010 8:47 pm 
Offline
User avatar

Joined: Mon Apr 16, 2007 6:38 pm
Posts: 1222
konstantin_666: "Тем более, что они собрались всё флэшем завешать." - кто Они? Теория заговора?)

HTML-язык разметки текста. Им размечают текст. Текст им размечают. Гипертекст. Зачем в панелях гипертекст? Впрочем, в данной теме панели (в отрыве от сабжа) - оффтоп.

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

Freeman, понимаю идею, но вот какие есть соображения - если сделать такое разделение, какое предложил я, то можно считать все рисуемые элементы необязательными, все нерисуемые - обязательными.

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

А нерисование рисуемого объекта не повлияет ни на что, кроме самого объекта.

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

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


Top
   
PostPosted: Thu Aug 19, 2010 8:57 pm 
Offline
User avatar

Joined: Mon Apr 16, 2007 6:38 pm
Posts: 1222
Андрей Михайлович, (кстати, классный ник, одно удовольствие обращаться) все проще даже)
0х00 - некий графический объект дополнительный (он не обязательно не влез! может, некая программа захотела свой тип объекта в своих файлах использовать - пусть нулевой объект и будет для этих целей использоваться), 0xFF - то же для неграфических (если мы таки введем разделение. если нет - пусть будет объектом "конец рисунка", с какими-то, на всякий случай, своими свойствами), а среди свойств (тут про запас можно для битмапа хоть двойное слово отдать. Или так - в первом байте битмапа один из бит пусть говорит, есть ли еще байт бисмапа - и так до 4х байт) будет его номер


Last edited by Gluk on Thu Aug 19, 2010 9:06 pm, edited 1 time in total.

Top
   
PostPosted: Thu Aug 19, 2010 9:05 pm 
Offline
User avatar

Joined: Mon Apr 16, 2007 6:38 pm
Posts: 1222
Asper, в начале где-то был пример рисунка в где-то 43 байта. В разработке формата врядли эта цифра изменится, но пусть будет 50 байт. Сколько будет занимать такой же рисунок в формате SWF (без заголовков файла, и отдельно с)? можно и прикрепить его сюда. Конечно, мусор от редакторов надо выкинуть (если это возможно, если нет - это в минус формату, я считаю, в данном контексте), а лучше написать без редакторов (не настаиваю, т.к. формата и степени его сложности я не представляю), но при этом чтобы он продолжал валидно воспроизводиться просмотрщиками (и без ошибок с ворнингами), так же я бы взглянул на вывод gnash при парсинге этого файла (тоже очень желательно приложить, у меня нет под рукой компьютера, чтобы сделать это самому).

Эти просьбы связаны с тем, что этот вариант не отбрасывается


Last edited by Gluk on Thu Aug 19, 2010 9:13 pm, edited 1 time in total.

Top
   
PostPosted: Thu Aug 19, 2010 9:13 pm 
Offline
User avatar

Joined: Sat Feb 20, 2010 1:27 pm
Posts: 41
А теперь по теме "разрабатываемого" формата.
Gluk почему-то не учёл один мааааленький ньюанс.
Если то, что мы собираемся создать является форматом данных, то и начинать мы должны с типов этих самых данных.
Если формат и размер операндов полностью будет определять команда, то формат получится очень ограниченым и цитирую: "избыточным" (то есть полным нулей, которые нужно сжимать).
Мало того, это приведёт к отсутствию выравнивания объектов. Чем это грозит? Полной несовместимостью!
Например, решили мы сэкономить пару килобайтов в библиотеке и выбросили оттуда пару определений команд. Парсер доходит до средины документа и встречает неизвестную команду. Всё. Ошибка (или даже зависание).
Данная проблема существует во практически во всех парсерах байт-кода (в том числе и флэш).
Это значит, что совместимость файла и парсера должна быть 100% (в случае флэш готовьте 4 Мб под библиотеку).
Правда, если вы собираетесь исключительно "наращивать" библиотеку, можно довольствоваться обратной совместимостью.

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

И последнее: а как насчёт типов, например string?

_________________
Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда.


Last edited by konstantin_666. on Thu Aug 19, 2010 9:36 pm, edited 4 times in total.

Top
   
PostPosted: Thu Aug 19, 2010 9:18 pm 
Offline
User avatar

Joined: Fri Jun 27, 2008 3:22 pm
Posts: 988
Ok, завтра отпишусь.


Top
   
PostPosted: Thu Aug 19, 2010 9:18 pm 
Offline
User avatar

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

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


Top
   
PostPosted: Thu Aug 19, 2010 9:31 pm 
Offline
User avatar

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

"Например, решили мы сэкономить пару килобайтов в библиотеке и выбросили оттуда пару определений команд. Парсер доходит до средины документа и встречает неизвестную команду. Всё. Ошибка (или даже зависание).
Данная проблема существует во практически во всех парсерах байт-кода (в том числе и флэш)." - в постах к Freeman'у я описал поведение программы в такой ситуации. И там нет пункта "зависнуть"
А вообще да, команды, описанные в спецификации обязаны обрабатываться в программе, заявляющей что она умеет работать с таким форматом, соответствующим образом. И если автор программы нарочно нарушает требования спецификации - это целиком и полностью на его совести, думаю, пользователи откажутся не от формата, а от программы (формат может быть и внутренним - тогда пользователь и не знает что там за формат используется), если она падает или зависает там, где другая программа ни падает, ни зависает.

"И последнее: а как насчёт типов, например string?" - а что насчет них?

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


Top
   
PostPosted: Thu Aug 19, 2010 9:35 pm 
Offline
User avatar

Joined: Tue May 08, 2007 12:44 am
Posts: 353
Gluk, тогда формат можно рассматривать как компилированный SVG, по аналогии с CHM. И чтобы не городить огород, взять стандарт SVG и на его основе сделать стандарт двоичной кодификации. Тут сразу и число объектов, и атрибуты "посчитаются" (256 или больше). Иначе беспредметный спор.

Исхожу из того, что в комитете, разрабатывающем SVG, не дубы сидят, и наверняка собаку на векторной графике съели. В первой версии его можно поддержать не полностью, для того и совместимость.

Соответственно, для работы с форматом нужны компилятор и декомпилятор его в SVG. Сам формат, как понимаю, в памяти будет представлять некий аналог DOM.

Кстати, для SVG вроде стандартизирован SVZ (или как-то так), представляющий собой сжатый XML. Но сжимать можно и компилированный вариант, если есть чем.


Top
   
PostPosted: Thu Aug 19, 2010 9:41 pm 
Offline
User avatar

Joined: Mon Apr 16, 2007 6:38 pm
Posts: 1222
konstantin_666, когда я писал предыдущий пост, выделенной жирным цветом фразы не было, с ней чуть понятнее.
"Это значит, что совместимость файла и парсера должна быть 100% (в случае флэш готовьте 4 Мб под библиотеку)." - вот поэтому формат надо не "разрабатывать", а разрабатывать, чтобы не приходилось его постоянно изменять. Вообще форматы не меняются, а появляются новые версии, и обычно это делается только с целью добавить фич и исправить существующие проблемы.
Парсить такой формат программно удобно, и код явно не займет 4 мегабайта. К тому же КоОС это такая ОС, в которой почти все программы уже входят в дистрибутив. Тот, кто собирает дистрибутив, может и проследить чтобы в него не входили программы и библиотеки несовместимых версий (у нас провряет все сообщество на ночных сборках), и уведомить автора программы или библиотеки о том, что надо бы предоставить версию поновее (а если код есть на свн, и лицензия позволяет, это может сделать любой). Такое невозможно в проприетарных флэшплеерах, отсюда проблемы

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


Top
   
PostPosted: Thu Aug 19, 2010 9:42 pm 
Offline
User avatar

Joined: Sat Feb 20, 2010 1:27 pm
Posts: 41
Gluk "каких нулей? которые в битмаске? " - тех, байтов которые в данных

Freeman "SVG вроде стандартизирован SVZ" - W3C, они и хтмл разработали, который Вы сейчас браузером грузите.

А теперь вспомните сообщения типа: "невозможно отобразить, обновите флэш-плеер"

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

_________________
Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда.


Last edited by konstantin_666. on Thu Aug 19, 2010 10:01 pm, edited 1 time in total.

Top
   
PostPosted: Thu Aug 19, 2010 9:52 pm 
Offline
User avatar

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

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

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


Top
   
PostPosted: Thu Aug 19, 2010 9:55 pm 
Offline
User avatar

Joined: Mon Apr 16, 2007 6:38 pm
Posts: 1222
konstantin_666, в примере (который 43 байта) покажите эти нули. Или в своем (каркас спецификации предоставлен, номера команд берите любые).

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


Top
   
PostPosted: Thu Aug 19, 2010 10:04 pm 
Offline
User avatar

Joined: Mon Apr 16, 2007 6:38 pm
Posts: 1222
konstantin_666, "W3C, они и хтмл разработали, который Вы сейчас браузером грузите."
- Nokia и 3310 разработала, который меньше пяти лет мало у кого прослужил (или мог бы прослужить), и работал много дней без подзарядки, так почему вы не в восторге от N97?
- Microsoft и XP разработала, которую без сомнения можно назвать (в свое время) очень удачной ОС, и даже сейчас многие остаются на ней. Так почему вы не в восторге от Vista?

впрочем, я не об этом, SVG хорош, но не для Колибри

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


Top
   
PostPosted: Thu Aug 19, 2010 10:05 pm 
Offline
User avatar

Joined: Sat Feb 20, 2010 1:27 pm
Posts: 41
"1[10110000 -1байт](400 -2байта)(180 -1байт)(5 -2байта)2[10101100 -1байт](100 -2байта)(80ff0000 -4байта)(150 -2байта)(200 -2байта)2[10101100 -1байт](100 -2байта)(8000ff00 -4байта)(250 -2байта)(270 -2байта)2[10101100 -1байт](100 -2байта)(800000ff -4байта)(250 -2байта)(130 -2байта)"
А вообще пример явно неправдоподобный.
И что это за "80"?

W3C- некоммерческая организация, единственное на чём она держится- её принципы. Поэтому она их и придерживается. Поэтому и продукты выходят одинаково стабильные и совместимые.

_________________
Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда.


Last edited by konstantin_666. on Thu Aug 19, 2010 10:15 pm, edited 1 time in total.

Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 144 posts ]  Go to page Previous 1 2 3 4 510 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 3 guests


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