Вместо использования в рамках проекта КолибриОС несомненно замечательного формата SVG предлагаю разработать свой формат, и написать конвертеры в него. Формат должен быть бинарным и машинно-понятным (иначе нет смысла в этом). Предлагаю здесь обсудить спецификацию будущего формата. Я предлагаю также кандидата на каркас такой спецификации. Если вас он устраивает - давайте доведем каркас до, собственно, спецификации, если нет - предлагайте свои варианты.
[отсюда вырезано краткое описание, т.к. есть это в файлах]
сделать это не сложно (а парсить готовый такой код - дыки одно удовольствие), я делал нечто подобное (в действительности, довольно близкое) для хтмл, когда пытался делать браузер, и оно работало, причем неплохо. Но тогда это было чисто внутрипрограммное решение, а тут предлагаю в таком формате сохранять файлы, ну и хранить бинарно внутри программ-виджетов.
Кстати, можно использовать и всякие упрощения (тоже указать в спецификации), например если у прямоугольника задан только один размер - это квадрат (или линия возможно, в зависимости от того, какой из размеров задан), эллипс тогда - круг, ну и так далее. Эти варианты считайте приложенными к моему каркасу.
30.10.10 приложил начало спецификации. Там пока только то, что есть на форуме, нет описания объектов и их атрибутов. Однако все собрано в одном и том же месте, и без путаницы с изменениями. Примеров внутри нет, т.к. для них нужны описания объектов.
формат векторной графики
-
- Attachments
-
-
BFG(VS) specification.zip (124.84 KiB)
- начало спецификации.
Downloaded 443 times
-
Last edited by Gluk on Sat Oct 30, 2010 3:02 pm, edited 1 time in total.
ИМХО, это просто не имеет смысла и не прибавит никакой особой "производимости", потому как основное процессорное время уйдет на отрисовку, а не на парсинг. А объём можно уменьшить за счет сжатия, возможно, так будет даже компактней, чем байт-код.
Единственное, чего мы добъёмся- потеряем совместимость с довольно популярным (при чём, и в будущем) форматом.
Тем более, что я уже практически завершил работу над XML-парсером. На данный момент есть уже 5 тыс. строк на ассемблере. Осталось только тщательно всё отладить и оптимизировать. Библиотеку можно будет использовать и для браузера, так как в ней реализован пропуск пробелов и комментов, а также преобразование символов типа " " (обычно они преобразуются на уровне парсинга XML).
Оптимизация не должна проводиться за счет отсутствия совместимости. Большее значение имеет внутренняя оптимизация системы.
Единственное, чего мы добъёмся- потеряем совместимость с довольно популярным (при чём, и в будущем) форматом.
Тем более, что я уже практически завершил работу над XML-парсером. На данный момент есть уже 5 тыс. строк на ассемблере. Осталось только тщательно всё отладить и оптимизировать. Библиотеку можно будет использовать и для браузера, так как в ней реализован пропуск пробелов и комментов, а также преобразование символов типа " " (обычно они преобразуются на уровне парсинга XML).
Оптимизация не должна проводиться за счет отсутствия совместимости. Большее значение имеет внутренняя оптимизация системы.
Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда.
"Тем более, что я уже практически завершил работу над XML-парсером. На данный момент есть уже 5 тыс. строк на ассемблере. Осталось только тщательно всё отладить и оптимизировать. Библиотеку можно будет использовать и для браузера, так как в ней реализован пропуск пробелов и комментов, а также преобразование символов типа " " (обычно они преобразуются на уровне парсинга XML)." ровно то же я могу сказать по поводу того, что писал по поводу своей реализации в браузере. допилить это под свг - не сложная задача, просто у меня нет достаточного количества времени.
"Оптимизация не должна проводиться за счет отсутствия совместимости. Большее значение имеет внутренняя оптимизация системы." - Ваши пять тысяч строк против менее тысячи у меня (в случае с хтмл это оказалось именно так)
Производимости, может, это и не добавит, а вот производительности - вполне. И Вы серьезно считаете, что разgzипование и последующий парсинг это true-way?
Проверено (на примере браузера и хтмл) что преобразовать данные в такой вид и распарсить их затем - это довольно эффективный вариант парсинга вообще. То есть можно приводить данные в такой вид прямо из свг-файлов, и тут же обрабатывать их элементарнейшим алгоритмом - и вуаля - никакой страшной несовместимости.
Кстати, такой формат не только просто читается программой, но и составляется/редактируется. Думаю, помимо прочего, его можно использовать и в качестве входного кода для библиотек векторной графики
"Оптимизация не должна проводиться за счет отсутствия совместимости. Большее значение имеет внутренняя оптимизация системы." - Ваши пять тысяч строк против менее тысячи у меня (в случае с хтмл это оказалось именно так)
Производимости, может, это и не добавит, а вот производительности - вполне. И Вы серьезно считаете, что разgzипование и последующий парсинг это true-way?
Проверено (на примере браузера и хтмл) что преобразовать данные в такой вид и распарсить их затем - это довольно эффективный вариант парсинга вообще. То есть можно приводить данные в такой вид прямо из свг-файлов, и тут же обрабатывать их элементарнейшим алгоритмом - и вуаля - никакой страшной несовместимости.
Кстати, такой формат не только просто читается программой, но и составляется/редактируется. Думаю, помимо прочего, его можно использовать и в качестве входного кода для библиотек векторной графики
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Gluk (Вс янв 31, 2010 12:55 pm) wrote:пусть будет два проекта, конкуренция это хорошо
А у вас DOM реализован?Gluk wrote:Ваши пять тысяч строк против менее тысячи у меня (в случае с хтмл это оказалось именно так)
Как вы уже могли убедиться, даже машинный код нуждается в сжатии.Gluk wrote:И Вы серьезно считаете, что разgzипование и последующий парсинг это true-way?
А насчёт байт-кода скажу так: для мультимедийных файлов важна совместимость и раcширяемость, а производительность уже на втором плане. Вы серьёзно думаете, что ваш "формат" по совместимости и раcширяемости получится лучше, чем у 84 матёрых программистов , разработавших SVG?
Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда.
100% - ЗА.Gluk wrote:Вместо использования в рамках проекта КолибриОС несомненно замечательного формата SVG предлагаю разработать свой формат, и написать конвертеры в него. Формат должен быть бинарным и машинно-понятным (иначе нет смысла в этом). Предлагаю здесь обсудить спецификацию будущего формата.
Простой и компактный байт-код мог бы
- радикально разгрузить графическую подсистему, которая сейчас завалена абсурдно-примитивными GUI-вызовами в стиле MeOS;
- облегчить код приложений, избавить их от ряда низкоуровневых оконных операций;
- оптимизировать многократное рисование одинаковых элементов (глифов);
- реализовать эффективное масштабирование, скроллинг и перерисовку изображений;
- в дальнейшем стать основой для аппаратной акселерации GUI.
Правда, чем дольше я думаю над конкретным форматом такого кода, тем ближе он оказывается к PDF...
Last edited by art_zh on Wed Aug 18, 2010 1:26 pm, edited 1 time in total.
Евангелие от Иоанна: стих 1[/size]
Code: Select all
; В начале было Слово:
B32: mov ax, os_stack ; Selector for os
Может проголосовать?
Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда.
"Вы серьёзно думаете, что ваш "формат" по совместимости и ра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 таких рисунков.
"А у вас 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 таких рисунков.
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
konstantin_666, я правильно понимаю, что, в то время как я предложил создать формат байт-кода для векторной графики всем заинтересованным, Вы предлагаете проголосовать насчет того чтобы отменить такое создание? а что если, скажем, лишь два человека проголосуют за этот формат и они же будут его разрабатывать, Вы предложите закрыть на основании голосования тему обсуждения и запретить разработку стандарта? Ну я все-таки надеюсь что я не прав, но тогда я совершенно не понимаю насчет чего тут можно голосовать. Я не предлагаю везде использовать именно такой формат, вступительное предложение в этой теме - вовсе не призыв отказываться от иных вариантов поддержки SVG, более того, Вы проделали большую работу в этом направлении -отказываться от нее я тоже не прошу. Так насчет чего же голосовать?
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Не понимаю, где вы нашли слово "парсер".konstantin_666. wrote:А у вас DOM реализован?
Опять вы основываете всё лишь на предположениях.Gluk wrote:Вы предлагаете проголосовать насчет того чтобы отменить такое создание?
Я предлагал просто проголосовать.
Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда.
SVG не может быть основой нового GUI,
а байт-код - вполне...
а байт-код - вполне...
В общем, если считаете нужным- делайте байт-код.
Но я в этом не участвую.
Но я в этом не участвую.
Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда.
Очень жаль.konstantin_666. wrote:В общем, если считаете нужным- делайте байт-код.
Но я в этом не участвую.
Можно было бы объединить усилия и решать задачу с двух концов
Ведь SVG все равно надо во что-то компилить.
Чем байт-код хуже гирлянды mcall'ов?
Мда, какие громкие разборки абсолютно на пустой почве.
В Колибри вообще-то каждый занимается тем - чем ему нравится, а вопрос поддержать или не поддержать ту или иную разработку всегда за конечными пользователями. В данном случае за программистами использующими стандарт.
Я вот до сих пор не понимаю - мне пытались запретить дальнейшую разработку zSea на основании того, что нужно дорабатывать libimg. Смешно, ей богу.
Gluk
Делай свое дело - это твое личное право делать, что вздумается и как вздумается.
Главное документацию составлять не забывай, в противном случае будешь писать один, а это сам понимаешь непродуктивно.
В Колибри вообще-то каждый занимается тем - чем ему нравится, а вопрос поддержать или не поддержать ту или иную разработку всегда за конечными пользователями. В данном случае за программистами использующими стандарт.
Я вот до сих пор не понимаю - мне пытались запретить дальнейшую разработку zSea на основании того, что нужно дорабатывать libimg. Смешно, ей богу.
Gluk
Делай свое дело - это твое личное право делать, что вздумается и как вздумается.
Главное документацию составлять не забывай, в противном случае будешь писать один, а это сам понимаешь непродуктивно.
Вообще как вариант можно использовать флэш (SWF) формат, это и есть байт-код и при этом стандарт. А на счет проприетарности скажу, что Adobe давно уже открыла спецификацию, да и gnash и другие свободные программы никто ведь не запрещает.
"Не понимаю, где вы нашли слово "парсер"."
- вот тут, дважды: "Тем более, что я уже практически завершил работу над XML-парсером. На данный момент есть уже 5 тыс. строк на ассемблере. Осталось только тщательно всё отладить и оптимизировать. Библиотеку можно будет использовать и для браузера, так как в ней реализован пропуск пробелов и комментов, а также преобразование символов типа " " (обычно они преобразуются на уровне парсинга XML)." именно этот код и код моего парсера (менее 1000 строк) обсуждался
"Я предлагал просто проголосовать." - т.е. без какой-либо конкретной цели, не планируя как-либо использовать результаты, так - поголосовать от нечего делать? конечно, мне приходится довольствоваться своими предположениями, раз достоверная интересующая меня информация умалчивается (а именно "по какому поводу голосовать").
- вот тут, дважды: "Тем более, что я уже практически завершил работу над XML-парсером. На данный момент есть уже 5 тыс. строк на ассемблере. Осталось только тщательно всё отладить и оптимизировать. Библиотеку можно будет использовать и для браузера, так как в ней реализован пропуск пробелов и комментов, а также преобразование символов типа " " (обычно они преобразуются на уровне парсинга XML)." именно этот код и код моего парсера (менее 1000 строк) обсуждался
"Я предлагал просто проголосовать." - т.е. без какой-либо конкретной цели, не планируя как-либо использовать результаты, так - поголосовать от нечего делать? конечно, мне приходится довольствоваться своими предположениями, раз достоверная интересующая меня информация умалчивается (а именно "по какому поводу голосовать").
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Who is online
Users browsing this forum: No registered users and 8 guests