Board.KolibriOS.org

Official KolibriOS board
It is currently Sun Dec 15, 2019 9:12 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 144 posts ]  Go to page 1 2 3 4 510 Next
Author Message
PostPosted: Wed Aug 18, 2010 8:44 am 
Offline
User avatar

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

[отсюда вырезано краткое описание, т.к. есть это в файлах]

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

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

30.10.10 приложил начало спецификации. Там пока только то, что есть на форуме, нет описания объектов и их атрибутов. Однако все собрано в одном и том же месте, и без путаницы с изменениями. Примеров внутри нет, т.к. для них нужны описания объектов.


Attachments:
File comment: начало спецификации.
BFG(VS) specification.zip [124.84 KiB]
Downloaded 251 times


Last edited by Gluk on Sat Oct 30, 2010 3:02 pm, edited 1 time in total.
Top
   
PostPosted: Wed Aug 18, 2010 9:44 am 
Offline
User avatar

Joined: Sat Feb 20, 2010 1:27 pm
Posts: 41
ИМХО, это просто не имеет смысла и не прибавит никакой особой "производимости", потому как основное процессорное время уйдет на отрисовку, а не на парсинг. А объём можно уменьшить за счет сжатия, возможно, так будет даже компактней, чем байт-код.
Единственное, чего мы добъёмся- потеряем совместимость с довольно популярным (при чём, и в будущем) форматом.

Тем более, что я уже практически завершил работу над XML-парсером. На данный момент есть уже 5 тыс. строк на ассемблере. Осталось только тщательно всё отладить и оптимизировать. Библиотеку можно будет использовать и для браузера, так как в ней реализован пропуск пробелов и комментов, а также преобразование символов типа "&nbsp" (обычно они преобразуются на уровне парсинга XML).

Оптимизация не должна проводиться за счет отсутствия совместимости. Большее значение имеет внутренняя оптимизация системы.

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


Top
   
PostPosted: Wed Aug 18, 2010 10:08 am 
Offline
User avatar

Joined: Mon Apr 16, 2007 6:38 pm
Posts: 1222
"Тем более, что я уже практически завершил работу над XML-парсером. На данный момент есть уже 5 тыс. строк на ассемблере. Осталось только тщательно всё отладить и оптимизировать. Библиотеку можно будет использовать и для браузера, так как в ней реализован пропуск пробелов и комментов, а также преобразование символов типа "&nbsp" (обычно они преобразуются на уровне парсинга XML)." ровно то же я могу сказать по поводу того, что писал по поводу своей реализации в браузере. допилить это под свг - не сложная задача, просто у меня нет достаточного количества времени.

"Оптимизация не должна проводиться за счет отсутствия совместимости. Большее значение имеет внутренняя оптимизация системы." - Ваши пять тысяч строк против менее тысячи у меня (в случае с хтмл это оказалось именно так)

Производимости, может, это и не добавит, а вот производительности - вполне. И Вы серьезно считаете, что разgzипование и последующий парсинг это true-way?

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

Кстати, такой формат не только просто читается программой, но и составляется/редактируется. Думаю, помимо прочего, его можно использовать и в качестве входного кода для библиотек векторной графики

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


Top
   
PostPosted: Wed Aug 18, 2010 10:35 am 
Offline
User avatar

Joined: Sat Feb 20, 2010 1:27 pm
Posts: 41
Gluk (Вс янв 31, 2010 12:55 pm) wrote:
пусть будет два проекта, конкуренция это хорошо


Gluk wrote:
Ваши пять тысяч строк против менее тысячи у меня (в случае с хтмл это оказалось именно так)

А у вас DOM реализован?
Gluk wrote:
И Вы серьезно считаете, что разgzипование и последующий парсинг это true-way?

Как вы уже могли убедиться, даже машинный код нуждается в сжатии.
А насчёт байт-кода скажу так: для мультимедийных файлов важна совместимость и раcширяемость, а производительность уже на втором плане. Вы серьёзно думаете, что ваш "формат" по совместимости и раcширяемости получится лучше, чем у 84 матёрых программистов :), разработавших SVG?

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


Top
   
PostPosted: Wed Aug 18, 2010 12:30 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1359
Gluk wrote:
Вместо использования в рамках проекта КолибриОС несомненно замечательного формата SVG предлагаю разработать свой формат, и написать конвертеры в него. Формат должен быть бинарным и машинно-понятным (иначе нет смысла в этом). Предлагаю здесь обсудить спецификацию будущего формата.

100% - ЗА.
Простой и компактный байт-код мог бы
- радикально разгрузить графическую подсистему, которая сейчас завалена абсурдно-примитивными GUI-вызовами в стиле MeOS;
- облегчить код приложений, избавить их от ряда низкоуровневых оконных операций;
- оптимизировать многократное рисование одинаковых элементов (глифов);
- реализовать эффективное масштабирование, скроллинг и перерисовку изображений;
- в дальнейшем стать основой для аппаратной акселерации GUI.

Правда, чем дольше я думаю над конкретным форматом такого кода, тем ближе он оказывается к PDF...

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков


Last edited by art_zh on Wed Aug 18, 2010 1:26 pm, edited 1 time in total.

Top
   
PostPosted: Wed Aug 18, 2010 12:50 pm 
Offline
User avatar

Joined: Sat Feb 20, 2010 1:27 pm
Posts: 41
Может проголосовать?

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


Top
   
PostPosted: Wed Aug 18, 2010 1:05 pm 
Offline
User avatar

Joined: Mon Apr 16, 2007 6:38 pm
Posts: 1222
"Вы серьёзно думаете, что ваш "формат" по совместимости и раcширяемости получится лучше, чем у 84 матёрых программистов :), разработавших SVG?" - я серьезно думаю что он проще алгоритмизуется и быстрее выполняется, а при должной степени проработки может повторить основные возможности SVG. его проще использовать при межпрограммном (программно-библиотечном, как вариант) взаимодействии, проще изменять/создавать программно.

"А у вас DOM реализован?" - DOM реализуется не на уровне парсера

P.S.
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байта)

картинка размером 400*400 пикселей, прямоугольник 400*400 без заливки с границей толщиной 5пикселей, прозрачностью границы 0.7, и в нем три круга с половинной прозрачностью, смещенные относительно центра.

я насчитал 43 байта кода. для сравнения описание (текст из предыдущего абзаца; в однобайтовой кодировке) - 206 байт, это почти 5 таких рисунков.

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


Top
   
PostPosted: Wed Aug 18, 2010 1:17 pm 
Offline
User avatar

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

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


Top
   
PostPosted: Wed Aug 18, 2010 1:26 pm 
Offline
User avatar

Joined: Sat Feb 20, 2010 1:27 pm
Posts: 41
konstantin_666. wrote:
А у вас DOM реализован?

Не понимаю, где вы нашли слово "парсер".
Gluk wrote:
Вы предлагаете проголосовать насчет того чтобы отменить такое создание?

Опять вы основываете всё лишь на предположениях.
Я предлагал просто проголосовать.

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


Top
   
PostPosted: Wed Aug 18, 2010 1:37 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1359
SVG не может быть основой нового GUI,

а байт-код - вполне...


Top
   
PostPosted: Wed Aug 18, 2010 1:43 pm 
Offline
User avatar

Joined: Sat Feb 20, 2010 1:27 pm
Posts: 41
В общем, если считаете нужным- делайте байт-код.
Но я в этом не участвую.

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


Top
   
PostPosted: Wed Aug 18, 2010 1:52 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1359
konstantin_666. wrote:
В общем, если считаете нужным- делайте байт-код.
Но я в этом не участвую.

Очень жаль.
Можно было бы объединить усилия и решать задачу с двух концов
Ведь SVG все равно надо во что-то компилить.
Чем байт-код хуже гирлянды mcall'ов?


Top
   
PostPosted: Wed Aug 18, 2010 1:56 pm 
Мда, какие громкие разборки абсолютно на пустой почве.
В Колибри вообще-то каждый занимается тем - чем ему нравится, а вопрос поддержать или не поддержать ту или иную разработку всегда за конечными пользователями. В данном случае за программистами использующими стандарт.
Я вот до сих пор не понимаю - мне пытались запретить дальнейшую разработку zSea на основании того, что нужно дорабатывать libimg. Смешно, ей богу. :lol:

Gluk
Делай свое дело - это твое личное право делать, что вздумается и как вздумается. :D
Главное документацию составлять не забывай, в противном случае будешь писать один, а это сам понимаешь непродуктивно.


Top
   
PostPosted: Wed Aug 18, 2010 2:03 pm 
Offline
User avatar

Joined: Fri Jun 27, 2008 3:22 pm
Posts: 988
Вообще как вариант можно использовать флэш (SWF) формат, это и есть байт-код и при этом стандарт. А на счет проприетарности скажу, что Adobe давно уже открыла спецификацию, да и gnash и другие свободные программы никто ведь не запрещает.


Top
   
PostPosted: Wed Aug 18, 2010 2:03 pm 
Offline
User avatar

Joined: Mon Apr 16, 2007 6:38 pm
Posts: 1222
"Не понимаю, где вы нашли слово "парсер"."
- вот тут, дважды: "Тем более, что я уже практически завершил работу над XML-парсером. На данный момент есть уже 5 тыс. строк на ассемблере. Осталось только тщательно всё отладить и оптимизировать. Библиотеку можно будет использовать и для браузера, так как в ней реализован пропуск пробелов и комментов, а также преобразование символов типа "&nbsp" (обычно они преобразуются на уровне парсинга XML)." именно этот код и код моего парсера (менее 1000 строк) обсуждался

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

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


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

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 0 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:  
Powered by phpBB® Forum Software © phpBB Limited