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

Wed Aug 18, 2010 8:44 am

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

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

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

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

возможно, в зависимости от того, какой из размеров задан), эллипс тогда - круг, ну и так далее. Эти варианты считайте приложенными к моему каркасу.

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

Wed Aug 18, 2010 9:44 am

ИМХО, это просто не имеет смысла и не прибавит никакой особой "производимости", потому как основное процессорное время уйдет на отрисовку, а не на парсинг. А объём можно уменьшить за счет сжатия, возможно, так будет даже компактней, чем байт-код.
Единственное, чего мы добъёмся- потеряем совместимость с довольно популярным (при чём, и в будущем) форматом.

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

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

Wed Aug 18, 2010 10:08 am

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

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

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

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

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

Wed Aug 18, 2010 10:35 am

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

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

А у вас DOM реализован?

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

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

, разработавших SVG?

Wed Aug 18, 2010 12:30 pm

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

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

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

Wed Aug 18, 2010 12:50 pm

Может проголосовать?

Wed Aug 18, 2010 1:05 pm

"Вы серьёзно думаете, что ваш "формат" по совместимости и ра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 таких рисунков.

Wed Aug 18, 2010 1:17 pm

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

Wed Aug 18, 2010 1:26 pm

konstantin_666. wrote:А у вас DOM реализован?

Не понимаю, где вы нашли слово "парсер".

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

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

Wed Aug 18, 2010 1:37 pm

SVG не может быть основой нового GUI,

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

Wed Aug 18, 2010 1:43 pm

В общем, если считаете нужным- делайте байт-код.
Но я в этом не участвую.

Wed Aug 18, 2010 1:52 pm

konstantin_666. wrote:В общем, если считаете нужным- делайте байт-код.
Но я в этом не участвую.

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

Wed Aug 18, 2010 1:56 pm

Мда, какие громкие разборки абсолютно на пустой почве.
В Колибри вообще-то каждый занимается тем - чем ему нравится, а вопрос поддержать или не поддержать ту или иную разработку всегда за конечными пользователями. В данном случае за программистами использующими стандарт.
Я вот до сих пор не понимаю - мне пытались запретить дальнейшую разработку zSea на основании того, что нужно дорабатывать libimg. Смешно, ей богу.

Gluk
Делай свое дело - это твое личное право делать, что вздумается и как вздумается.

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

Wed Aug 18, 2010 2:03 pm

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

Wed Aug 18, 2010 2:03 pm

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

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

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

Who is online