Comments 30
Вы вовремя, вот на днях занимался чтением svg. Спасибо. Будет время и необходимость, попробую потестировать и дополнить вашу библиотеку.
Только одно мне не нравится, это зависимость к boost. Слишком он громоздкий как по мне, если нужно будет куда-то подключить SVG++, то придется с ним возиться. К примеру для Android или iOS, это будет головня немного.
Только одно мне не нравится, это зависимость к boost. Слишком он громоздкий как по мне, если нужно будет куда-то подключить SVG++, то придется с ним возиться. К примеру для Android или iOS, это будет головня немного.
Есть nanosvg — не такая громоздкая и без адовых зависимостей. github.com/memononen/nanosvg
Почему многие так боятся boost? Да там половина всего — чистейшие header-only библиотеки, в частности и mpl. И никаких проблем при сборке под мобильные платформы быть не должно.
Ну и монструозность буста преувеличена — ведь это практически полигон для обкатки новых частей stl. Тот же std::array в c++11 пришёл из буста. Но std::array используем, а boost::array — нет, видите ли громоздкий слишком.
Ну и монструозность буста преувеличена — ведь это практически полигон для обкатки новых частей stl. Тот же std::array в c++11 пришёл из буста. Но std::array используем, а boost::array — нет, видите ли громоздкий слишком.
Согласен!!! куча прикольных вещей в stl пришла именно из буста
Я его не боюсь, он мне даже нравится. Но как бы для маленького проекта тянуть его просто не круто, это мое мнение.
github.com/MysticTreeGames/Boost-for-Android
позволяет собрать Boost для андройда без проблем
позволяет собрать Boost для андройда без проблем
На «дополнить» особо не рассчитывайте) Покрытие спецификации у SVG++ вполне хорошее. А вот тестирование и любой фидбэк приветствуется.
Насчет Boost. SVG++ — header-only library, то есть достаточно распаковать Boost и добавить его в include paths, билдить ничего из буста не надо.
Насчет Boost. SVG++ — header-only library, то есть достаточно распаковать Boost и добавить его в include paths, билдить ничего из буста не надо.
Используем в проекте сборку skia (http://en.wikipedia.org/wiki/Skia_Graphics_Engine, github.com/SBKarr/skia.git — если интересно). Тяжеловато (примерно +2.5мб), но интеграция удобна и в связке с cocos2d-x нет дополнительных зависимостей. Кроме того, вместе с svg есть ещё и произвольное векторное рисование. На выходных думал написать про это всё, но обычно такие мысли у меня до дела не доходят.
А где там смотреть чтение SVG?
В том и проблема, библиотека крута, а документации очень мало. Чем и хотелось бы заняться. А здесь написал, чтобы привлечь внимание к проблеме.
До того, как начали использовать skia перебрали чёртову кучу вариантов, включая nanosvg, SVGKit
для ios, что-то похожее на дроиде. Вдруг кто-то ещё ищет подобное решение, тема к этому распологает.
До того, как начали использовать skia перебрали чёртову кучу вариантов, включая nanosvg, SVGKit
для ios, что-то похожее на дроиде. Вдруг кто-то ещё ищет подобное решение, тема к этому распологает.
Похоже, что чтения и нет, только создание. В этом и проблема SVG — создавать можно без проблем, используя только std::ofstream, а полноценное чтение мало кто может себе позволить.
И здесь ситуация тоже интересная, готовый интерпретатор есть в теле chromium, но сам API skia почти полностью соответствует спецификации SVG. Сделать парсер со skia в качестве возможного бекенда — задача не настолько сложная, как писать растеризацию вручную. Если сделать готовый набор средств, позволяющий рисовать SVG на всех мобильных девайсах без сложных зависимостей (libpng, libjpeg, freetype — дело обычное) — сообщество скажет огромное спасибо.
Векторные иконки и графика — это круто, но прямо сейчас нет готового набора средств, чтобы их использовать и на iOS, и на Android, и на любом девайсе, на котором можно запустить C++ код, включая ПК. Есть librsvg с совсем не либеральной GPL и зависимостью от тяжеленной cairo. Есть отдельные осколки под свою платформу вроде SVGKit с ограниченной функциональностью. Есть парсеры без растеризации. Есть OpenVG, на который, похоже, все забили. И такая фигня продолжается уже лет 5. Надо создавать полноценную платформу, с чтением, рендерингом, сохранением и без жёстких ограничений по функциям.
Ваша идея крута, и реализация тоже. Но круче всего были бы готовые бекенды. Для skia, OpenVG, может даже cairo. Иначе — ситуация вокруг векторной графики с места не сдвинется. Сейчас кроссплатформенно даже нарисовать нельзя, не говоря об анимации и DOM.
Векторные иконки и графика — это круто, но прямо сейчас нет готового набора средств, чтобы их использовать и на iOS, и на Android, и на любом девайсе, на котором можно запустить C++ код, включая ПК. Есть librsvg с совсем не либеральной GPL и зависимостью от тяжеленной cairo. Есть отдельные осколки под свою платформу вроде SVGKit с ограниченной функциональностью. Есть парсеры без растеризации. Есть OpenVG, на который, похоже, все забили. И такая фигня продолжается уже лет 5. Надо создавать полноценную платформу, с чтением, рендерингом, сохранением и без жёстких ограничений по функциям.
Ваша идея крута, и реализация тоже. Но круче всего были бы готовые бекенды. Для skia, OpenVG, может даже cairo. Иначе — ситуация вокруг векторной графики с места не сдвинется. Сейчас кроссплатформенно даже нарисовать нельзя, не говоря об анимации и DOM.
Собственно, именно такие у меня планы. Сейчас демо приложение — это довольно продвинутый рендерер на AGG и добавить Skia и Cairo будет не особо сложно. Но сначала я решил отрелизить саму библиотеку.
Кстати, сразу возникает два варианта: 1) загружать SVG в промежуточные структуры, например DOM, это дает scripting и анимацию, но значительный оверхэд и сложнее реализация; 2) отрисовывать сразу в процессе чтения — проще код, меньше оверхэд по памяти.
Кстати, сразу возникает два варианта: 1) загружать SVG в промежуточные структуры, например DOM, это дает scripting и анимацию, но значительный оверхэд и сложнее реализация; 2) отрисовывать сразу в процессе чтения — проще код, меньше оверхэд по памяти.
На практике простой вывод на рендерер нужнее, чем анимация. Тем более, что средства для анимирования обычно есть у промежуточных объектов бекенда. Было бы хорошо реализовать оба варианта, но поскольку второй нужнее большинству пользователей и проще — его первым.
У нас в проекте востребовано изменение объектов в svg на ходу, одновременно с рисованием и сохранением, изредка нужна анимация. Решение такое — большую часть времени в памяти есть только готовая текстура. Контекст svg создаётся для изменения и сохранения новой текстуры, после чего убирается из памяти. Во время анимации контекст существует, пока анимация не закончилась, чтобы не было перераспределения памяти каждый кадр. На мобильных девайсах оверхед — зло даже большее, чем низкая производительность. Важно, чтобы инструменты позволяли изворачиваться и хранить в памяти только самое нужное.
У нас в проекте востребовано изменение объектов в svg на ходу, одновременно с рисованием и сохранением, изредка нужна анимация. Решение такое — большую часть времени в памяти есть только готовая текстура. Контекст svg создаётся для изменения и сохранения новой текстуры, после чего убирается из памяти. Во время анимации контекст существует, пока анимация не закончилась, чтобы не было перераспределения памяти каждый кадр. На мобильных девайсах оверхед — зло даже большее, чем низкая производительность. Важно, чтобы инструменты позволяли изворачиваться и хранить в памяти только самое нужное.
документация готовится к переводу на английский, поэтому временный mishmash русского and english языков
Надеюсь, русский язык не выпилите вообще из документации?
Собираюсь выпилить) Поддерживать документацию на двух языках накладно. Но вы заставили меня задуматься
Вы же всё равно пишете сначала на русском, а потом переводите, как я понял. Зачем же уничтожать этот труд? Не хотите поддерживать — ради бога, только зачем выпиливать то, что уже существует? Положите отдельно, напишите про неактуальность, если всё так печально. Новичкам, по крайней мере, будет облегчен старт.
Это Спартаааа!
может лучше сначала выучить хотя бы базовый английский? иначе потом термины невозможно читать… техническая информация на русском как-то… не читается, что ли… имхо :)
Английский я знаю на довольно неплохом уровне, для чтения технической документации хватает, по крайней мере. Вы попробуйте сначала почитать на русском что-нибудь, а потом говорите о «не читается». Если написано толково, никаких проблем не возникает. Тем более, автор русскоязычный, глупо отворачиваться от родного языка.
Вопрос: демо-приложение, входящее в состав библиотеки, умеет отрисовывать SVG с градиентной заливкой? С тенями?
На самом деле, без CSS и прочих анимаций вполне можно обойтись, но вот градиенты и blur при рисовании чего-либо хоть сколько-то красивого — must have.
На самом деле, без CSS и прочих анимаций вполне можно обойтись, но вот градиенты и blur при рисовании чего-либо хоть сколько-то красивого — must have.
Демо-приложение умеет рисовать градиенты (по крайней мере, с AGG). Здесь можно скачать (регистрация открытая) SVG Test Suite рендеренный с помощью демо, чтобы примерно представлять реализованнные в демо фичи. Тени в демо не сделаны.
Но нужно понимать мотивацию при создании компонент — библиотека SVG++ умеет читать всё, а демо показывает как этим пользоваться, включая реализацию сложных функций. Но, например, полная реализации фильтров раздула бы демо-приложение кучей довольно тривиального кода.
Но нужно понимать мотивацию при создании компонент — библиотека SVG++ умеет читать всё, а демо показывает как этим пользоваться, включая реализацию сложных функций. Но, например, полная реализации фильтров раздула бы демо-приложение кучей довольно тривиального кода.
На самом деле, полная поддержка всех фич SVG мало, кому нужна. Нужно, как в старом анекдоте, «достаточно близко для любых практических целей».
По факту, я, например, хотел бы слепить плоский движок с возможностью отрисовывать картинки, созданные в Inkscape.
Насчет «тривиального кода» — поверю вам на слово, что добавить все фильтры будет тривиально, хотя вообще говоря, там всё весьма и весьма непросто для человека, который раньше в это не влезал.
Думаю, вы согласитесь, что большая часть случаев парсинга SVG — это его отображение. Иначе зачем вообще парсить графический формат? :) И AGG, скажем, для отрисовки подходит идеально.И если сделать более-менее полнофункциональное SVG-демо, то оно было бы не только шикарной рекламой библиотеке svg++, но и удобным подспорьем для людей, которые просто хотят всем этим пользоваться. Без особых мучений. Более-менее «из коробки».
Я бы вам порекомендовал, даже попросил, особенно, если это несложно, добавить blur (который нужен для теней).
По факту, я, например, хотел бы слепить плоский движок с возможностью отрисовывать картинки, созданные в Inkscape.
Насчет «тривиального кода» — поверю вам на слово, что добавить все фильтры будет тривиально, хотя вообще говоря, там всё весьма и весьма непросто для человека, который раньше в это не влезал.
Думаю, вы согласитесь, что большая часть случаев парсинга SVG — это его отображение. Иначе зачем вообще парсить графический формат? :) И AGG, скажем, для отрисовки подходит идеально.И если сделать более-менее полнофункциональное SVG-демо, то оно было бы не только шикарной рекламой библиотеке svg++, но и удобным подспорьем для людей, которые просто хотят всем этим пользоваться. Без особых мучений. Более-менее «из коробки».
Я бы вам порекомендовал, даже попросил, особенно, если это несложно, добавить blur (который нужен для теней).
В качестве черного ящика «на входе SVG, на выходе растр», имхо, вполне можно использовать Qt SVG.
SVG++ нацеливалась на тех, кого не устраивает черный ящик или есть особые требования по памяти/производительности.
Например, в программе уже используется Skia/Cairo/GDI+/AGG/etc в качестве движка и хочется рендерить SVG именно с помощью того же самого. В этом случае мало поможет то, что я допилил реализацию для одного движка.
Чтобы с помощью фильтров делать интересные эффекты (хотя бы как сэмплы в SVG Spec), нужно довольно большое их число реализовать. Одним blur не обойтись.
SVG++ нацеливалась на тех, кого не устраивает черный ящик или есть особые требования по памяти/производительности.
Например, в программе уже используется Skia/Cairo/GDI+/AGG/etc в качестве движка и хочется рендерить SVG именно с помощью того же самого. В этом случае мало поможет то, что я допилил реализацию для одного движка.
Чтобы с помощью фильтров делать интересные эффекты (хотя бы как сэмплы в SVG Spec), нужно довольно большое их число реализовать. Одним blur не обойтись.
Меня не устраивает черный ящик. И я с удовольствием поучаствую. Но порог вхождения должен быть таким, чтобы НАЧАТЬ было просто.
Что до Qt, в нем меня не устраивает лицензия.
Вы неправы. Реализация для одного движка упростит понимания реализации для другого. Большинству программистов читать код приятнее и проще, чем спецификации. И, напримр, переделать с AGG на SKIA гораздо легче, чем писать для SKIA с нуля, гадая, всё ли ты добавил и верная ли у тебя логика.
Разумеется, но он во-первых иллюстрирует, как добавить имплементацию фильтра (а остальные можно сделать по аналогии), а во-вторых, является самым распространенным и востребованным.
Что до Qt, в нем меня не устраивает лицензия.
В этом случае мало поможет то, что я допилил реализацию для одного движка.
Вы неправы. Реализация для одного движка упростит понимания реализации для другого. Большинству программистов читать код приятнее и проще, чем спецификации. И, напримр, переделать с AGG на SKIA гораздо легче, чем писать для SKIA с нуля, гадая, всё ли ты добавил и верная ли у тебя логика.
Одним blur не обойтись.
Разумеется, но он во-первых иллюстрирует, как добавить имплементацию фильтра (а остальные можно сделать по аналогии), а во-вторых, является самым распространенным и востребованным.
Sign up to leave a comment.
Чтение SVG в C++