Другие случайные мысли (не все мои):

• Мы действительно хотим избежать поддержки формата, в котором ранее существовало ожидание реализации функций, которые не будут работать. Например, внедрение SVG приведет к тому, что люди будут ожидать полной поддержки SVG, включая сценарии, HTML, SMIL и т. д.
• Мы должны разработать наш формат, явно очень тесно связанный с функциями производительности в Skia, например, drawAtlas.

Поддержка векторов кажется решающей для платформы приложений, поддерживающей различные размеры и плотности экрана. В противном случае вы получите значки, которые выглядят так:

Вместо этого:

@ХансМюллер

Крис также упомянул об этом: мы могли бы выполнять некоторую ограниченную обработку SVG во время сборки. Например, мы можем создавать виджеты значков MD на основе описаний SVG. Если все сделано аккуратно, это может сэкономить место и повысить точность исходного дизайна.

В частности, для значков материального дизайна мы должны изучить использование шрифта значков материального дизайна.

@appsforartists Как бы то ни было, ни Cocoa, ни android.view не используют векторные форматы для значков.

@abarth Меня не удивляет iOS — похоже, они начали с жестко запрограммированного 3,5-дюймового экрана и с тех пор очень старались сохранить эту ментальную модель / простоту поддерживаемых разрешений (см.: ширина каждого iPhone одинакова или оригинальный iPad и iPad mini имеют одинаковое разрешение).

В любом случае значки не должны выглядеть сглаженными, как на снимке экрана выше, а векторы — хорошее решение для независимости от разрешения. Как вы, ребята, решите реализовать красивые значки, зависит от вас. :смайлик:

Как вы, ребята, решите реализовать красивые значки, зависит от вас.

Не могли бы вы создать отдельный вопрос о проблеме с разрешением, которую вы видели со значками? @krisgiesing внедрил распознаватель ресурсов с учетом разрешения, который обрабатывает множество случаев. Было бы полезно узнать о случаях, которые он не обрабатывает.

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

Похоже, что 3x имеет соотношение пикселей устройства 2.6 , для которого у нас, вероятно, нет активов.

Я смотрю на этот конкретный случай сейчас. Соотношение пикселей устройства составляет 2,625; мы выбираем актив 3.0x, что и ожидается. Однако во время рендеринга происходит что-то, вызывающее дополнительные артефакты сглаживания. Так что, хотя @abarth исправила случай значков Material Design, переключившись на шрифт, я все еще исследую другие типы графических ресурсов, которым требуется масштабирование в зависимости от разрешения.

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

См. № 2337

Android поддерживает формат «VectorDrawable», который является просто хорошо работающим подмножеством SVG. Я надеюсь, что вы рассмотрите возможность использования того же формата, учитывая, что он уже имеет некоторую поддержку сообщества, и команда Android, по-видимому, сочла его производительность адекватной.

VectorDrawable, безусловно, находится под влиянием SVG, но это не его подмножество. Кроме того, он использует XML, что в значительной степени гарантирует, что он не будет самым производительным векторным форматом, который только можно было придумать. :-)

Было бы неправильно описывать VectorDrawable как строгое подмножество, но все же это кажется сбалансированным компромиссом между обеспечением хорошей производительности _render_ и простотой использования. Спецификация VectorDrawable часто опирается на спецификацию SVG в таких ключевых областях, как синтаксис данных пути, что значительно упрощает преобразование активов SVG, которые уже используют многие разработчики, и совместное использование VectorDrawables, которые уже содержатся в существующих приложениях для Android.

Я не могу себе представить, что XML является серьезным блокировщиком производительности, потому что он влияет только на синтаксический анализ. Мне кажется, что производительность _render_ — та производительность, которая влияет на цель Flutter в приложениях со скоростью 60 кадров в секунду — больше зависит от набора векторных операций, которые Skia должна будет отрисовать, а не от шага синтаксического анализа, который можно выполнить один раз и кэшировать.

Я не хочу зацикливаться на этом, но я не могу отделаться от ощущения, что работа для этого уже проделана, и поэтому ее не нужно откладывать на этап «после выпуска 2.0».

В итоге мы использовали шрифт Material Design для иконок Material Design. Я не знаю каких-либо препятствий, мешающих кому-то создать это поверх Flutter сегодня, используя прямые вызовы dart:ui или виджет CustomPaint: https://docs.flutter.io/flutter/widgets/CustomPaint-class. HTML. В настоящее время у нас нет планов строить такие.

$ 0,02 - даже дерьмовые браузеры ( и конкурентная среда React Native не имеет значения, их решение взломано) могут отображать SVG. Параметр экспорта изображения требует создания минимум 3 файлов для каждой иконки или художественного актива для моей команды. Это плохая практика по сравнению с тем, что один файл SVG может отображаться в любом разрешении.

Что касается приведенного выше комментария Хикси, ранее существовавшие ожидания не должны препятствовать внедрению полезной функции. Я бы предпочел иметь базовую поддержку отображения SVG (которая решает многие проблемы для меня и моей команды) и обнаружить, что расширенные параметры недоступны, чем полагаться на постоянно растущее количество PNG для удовлетворения постоянно растущего количество разрешений экрана.

Я возвращаюсь к созданию шрифта для своей команды, но это не так хорошо, как встроенная поддержка SVG, потому что формат шрифта добавляет дополнительное форматирование для высоты строки и межбуквенного интервала, которое необходимо настроить в приложении. Кроме того, шрифты должны отображаться с фиксированным разрешением (12 пикселей, 16 пикселей, 20 пикселей, 36 пикселей...), что также является ограничением.

Спасибо за крутой фреймворк Flutter. :)

Я бы посоветовал всем, кому нужна поддержка SVG, реализовать поддержку SVG в виде пакета Dart для Flutter.

Для тех, кто заинтересован, я бы указал на https://docs.flutter.io/flutter/dart-ui/dart-ui-library.html , которая является низкоуровневой библиотекой для рисования.

От команды: Библиотека Dart не является достаточно хорошим решением. Просто передаю.

Можете ли вы уточнить это? Вся структура Flutter представляет собой библиотеку Dart; все, что мы реализуем здесь, скорее всего, будет библиотекой Dart. Каковы требования к «достаточно хорошему»?

Например, я реализовал (простой, не исчерпывающий) синтаксический анализатор SVG в чистом Dart некоторое время назад:

https://github.com/matanlurey/svg

Вероятно, было бы несколько тривиально:

а. Создайте исполняемый SVG -> SvgRenderElement , который использует dart:ui под капотом.
б. Создайте шаг компиляции во время сборки, который преобразует SVG во что-то вроде:

// compiled from star.svg
void drawStarSvg(canvas, width, height) { ... }

@deborah-ufw, если вам интересно, мы будем рады поболтать, чтобы узнать больше. Вы можете написать мне по электронной почте?

Привет, Сет, матанлурей и Хикси. Большое спасибо за ответ. Я, вероятно, не тот человек, с которым можно подробно поговорить, поскольку именно наши ведущие инженеры отказались от плагина Dart (что привело к созданию огромной библиотеки png для нашего приложения, что также заставляет большинство из нас съеживаться).

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

Они также могут общаться с нашими инженерами напрямую через http://gitter.im/flutter/flutter, а также с помощью других способов связи, перечисленных https://flutter.io/support/, если это необходимо. :)

Я добавлю это. Спасибо! :D

Другой подход — интегрировать что-то вроде http://svgpp.org/ на нативном уровне и использовать систему плагинов Flutter для связи с ним. Это, вероятно, даст вам наилучшие характеристики размера/производительности для полной поддержки SVG, но за счет поддержания зависимости.

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

У меня сложилось впечатление, что Skia обеспечивает некоторую базовую поддержку SVG. Нет ли способа сделать это доступным для Flutter?

Насколько я могу судить, это было только экспериментальным и частичным. Здесь открыта проблема https://bugs.chromium.org/p/skia/issues/detail?id=5596 , но ей больше года. Они также указывают это в своей дорожной карте, но опять же не ясно, какой приоритет.

Не имеет смысла поддерживать SVG на уровне движка, потому что это не раскрывает модель документа SVG, которая является основной частью поддержки SVG.

Если Flutter поддерживает SVG, то конечной целью будет действительно поддержка настоящего SVG. Половинчатая реализация функций противоречит философии Flutter.

Я не считаю раскрытие модели документа SVG основной частью поддержки SVG. Было бы неплохо иметь это, но не обязательно для вариантов использования, которые я имею в виду.

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

Эта проблема явно серьезнее, но я был бы рад взять существующие ресурсы SVG и правильно отобразить их в разных разрешениях, не преобразовывая их все в громоздкие растровые изображения.

Да, импорт файла ресурсов SVG был бы действительно хорош, но спецификация для SVG составляет более 800 страниц. Сказав, что просто импортировать статические файлы для рендеринга в Skia (это библиотека векторной графики) не должно быть проблемой. Так что я беру это на себя; как обычно, я могу работать неполный рабочий день по выходным, так что сразу ничего не увидишь. Также у меня есть тонна SVG-файлов, но все они используют один и тот же материал (коллекции иконок из flaticon), поэтому я был бы признателен за образцы SVG-файлов от людей, которым нужна эта функция.

Карлос.

Я тоже немного заморачивался над этим со временем. Вот что я придумал:

Реализация уровня двигателя

Это кажется привлекательным по следующим причинам:

1. Теоретически поддерживает что-то вроде image: new AssetImage('graphics/background.svg') для анализа кода C/C++ и перевода данных SVG в команды рендеринга Skia.
2. По крайней мере, один хороший кандидат, который сможет довольно легко подключиться к Skia (https://github.com/svgpp/svgpp) на уровне движка.
3. Логика WebKit SVG была бы потрясающей, но, похоже, у нее слишком много зависимостей.
4. Я не думаю, что librsvg будет портироваться слишком хорошо (тесно связанный с Cairo, переход на Rust в качестве основного языка - нужно будет найти способ получить Skia как минимум в качестве бэкэнда)

Но у него есть как минимум несколько сложностей:

• Правильная обработка текста
• Правильная обработка CSS (если вообще? но добавить его — непростая задача)
• Расширение поддержки дополнительных функций (или предоставление пользователям возможности более изящно добавлять поддержку функций) является сложной задачей.
• Кажется, что очень сложно обрабатывать анимацию

Реализация уровня дротика

1. dart:ui Flutter предлагает множество примитивов от Skia, которые уже нужны SVG.
2. Я подозреваю, что рендеринг текста будет гораздо проще обрабатывать на этом уровне, чем на уровне движка.
3. Должно быть проще для большего количества сообщества поддерживать/расширять
4. Должна иметь возможность более дешево обрабатывать прямое взаимодействие с логикой синтаксического анализа (возможно, для обработки исключений и/или анимации?)

Но имеет несколько сложностей:

• Может не намного лучше поддерживать CSS
• Может не намного лучше поддерживать анимацию
• Вероятно, будет медленнее (но, возможно, недостаточно, чтобы иметь значение, и потенциально может быть компенсировано скомпилированным AOT SVG в код Dart)

Тестовые данные

Что касается примеров SVG, вероятно, было бы наиболее полезно определить, какие SVG поддерживаются из тестового набора 1.1 (или, если частично поддерживаются, что насчет них частично поддерживаются). Их можно найти здесь:
https://github.com/w3c/веб-платформа-тесты/дерево/мастер/svg/импорт

Или здесь с некоторыми сравнениями PNG: https://www.w3.org/Graphics/SVG/Test/20110816/

@cbazza , каким образом вы думаете реализовать это? На данный момент я больше склоняюсь к реализации уровня пакета Dart.

Кроме того, я думаю, что поддержка типов значков, вероятно, легко обрабатывается чем-то вроде IconData. Возможно, лучше рассматривать это отдельно, так как, вероятно, потребуется поддерживать только один путь для каждой кодовой точки.

Я думаю о «реализации уровня дротика» поверх dart: ui.

2 основных варианта использования:

(1) загрузите SVG-файлы статического значка чем-то вроде вашего
«изображение: новый AssetImage('graphics/background.svg')», где
файл мог прийти из файловой системы или по сети
динамически.

(2) Поддержка svg на основе виджета с DSX (JSX-подобная конструкция)
который будет очень похож на:
https://github.com/react-native-community/react-native-svg

Что касается «Тестовых данных», мне нужны настоящие файлы от людей, которым нужно
это, а не набор тестов w3. Поддержка SVG будет зависеть
на что поддерживает dart: ui , поэтому, если требуемый файл svg содержит
вещи, которые нельзя сделать с помощью dart:ui , я бы смог
узнать быстро.

Карлос.

Я не думаю, что нам следует использовать нативную модель SVG. Я хочу поддержать реальные случаи, но я думаю, что охват пакета w3 даст нам лучшее представление о том, что работает, а что нет, и насколько сложно это будет реализовать)

Ладно, видимо, какое-то недоразумение...
Когда я это сделаю (1), для этого потребуются стандартные файлы SVG, и я постараюсь поддерживать столько, сколько это возможно, учитывая dart: ui (Skia).
Когда я делаю (2), то есть создаю виджеты для обработки SVG-подобных конструкций, это будет очень похоже на эту библиотеку react-native-svg. Это 2 очень разные вещи.

@cbazza вариант использования svgs в нашем приложении в основном для одноцветных svgs, которые мы используем в качестве значков. Вот ссылка на zip-файл в Dropbox с подборкой последних svg, которые являются репрезентативными. https://www.dropbox.com/s/dp38wxc22625cvc/icons.zip?dl=0

Спасибо за интерес к помощи здесь, я был бы рад увидеть, как плагин SVG Flutter оживает!

Я написал инструмент, который выполняет минимальный синтаксический анализ последовательности файлов в формате SVG и выводит файлы Dart, которые мы позже используем для отображения анимации значков: vitool .

Я использовал этот инструмент для создания данных AnimatedIcons , вы можете проверить результат, запустив приложение ручного тестирования ( cd dev/manual_tests; flutter run -t lib/animated_icons.dart ).

Он далек от оптимального или полного, но работает с текущим набором анимированных иконок, который у нас есть, и кто-то должен чувствовать себя вправе разветвить/расширить его.

@deborah-ufw для этих одноцветных значков вы можете создать шрифт значков и отображать значки с помощью виджета значков .

@amirh не так просто создавать цветные векторные шрифты

@amirh , если вы прочитали всю ветку выше, создание и определение шрифта с глифами в качестве значков — это дополнительная серия шагов, которые необходимо выполнить, поскольку SVG не поддерживается. Поддержка SVG намного эффективнее шрифта. Кроме того, Zoechi прав — любое векторное изображение, имеющее несколько цветов, почти невозможно превратить в шрифт.

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

@deborah-ufw, спасибо за файлы, именно то, что я искал и уже нашел то, чего нет в моих файлах.

@amirh , да, я уже видел твою замечательную работу;)

Есть ли у нас, наконец, прямой способ получить svg или векторный xml актив в изображение для флаттера?

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

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

Из-за этого я не уверен, что сообщество Flutter преуспеет там, где сообщество Xamarin потерпело неудачу. Я считаю, что практично. Частичная поддержка значков SVG — это то, что команда Flutter могла бы предоставить, используя существующие примитивы Skia.

Это хорошо соответствует цели Flutter : позволить мобильным разработчикам создавать красивый и высокопроизводительный UX в рекордно короткие сроки . Это улучшит производительность, точность и производительность (SVG загружается намного быстрее, чем все эти PNG; пиктограммы SVG обычно требуют скромных вычислительных затрат, потому что требование визуальной ясности довольно часто приводит к форме умеренной сложности).

Основная потребность заключается в продуктивном рабочем процессе от широко используемых инструментов творческого дизайна (таких как Adobe) до масштабируемых собственных значков приложений.

Текущий подход PNG очень расточительный с точки зрения производительности и размера приложения; настолько примитивно генерировать и отправлять каждую иконку в виде 9 фиксированных растровых изображений (6 для Android, 3 для iOS), которые затем подвергаются пост-обработке во время выполнения. Проблема неуклонно возрастает по мере увеличения размера и разнообразия разрешений.
Это бросается в глаза в восхитительном инновационном и продуктивном опыте разработчиков Flutter. Я думаю, что у Flutter есть реальная возможность завоевать сердца и умы разработчиков,

Кроме того, @dnfield вышеупомянутые функции SVG , которые упоминаются как препятствия для реализации во Flutter, по моему опыту, либо не актуальны, либо достаточно редки, поэтому возврат к PNG для этих ресурсов дизайна является незначительным неудобством.
Не волнует: CSS, HTML, SMIL, модель документа, скрипты
Анимация, текст: достаточно редко, чтобы использовать для этого другие технологии.

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

@VincentH-Net Я на 100% с тобой, потому что я тоже чувствую боль!!! Пожалуйста, пришлите мне несколько ваших файлов SVG. Возможно, Xamarin изо всех сил пытался обеспечить поддержку SVG из-за отсутствия движка векторной графики, который мог бы с этим справиться; это не относится к Flutter со Skia, поэтому я очень оптимистичен, что решение сообщества будет найдено.

FWIW, Xamarin также имеет Skia, доступную в SkiaSharp. SVG может быть сложным даже для минимальной реализации.

Но @cbazza мне было бы очень интересно сотрудничать с вами в этом

А что касается анимации, я думаю, что включение Lottie удовлетворит множество вариантов использования (и, вероятно, сделает это с лучшими инструментами для дизайнеров).

@dnfield Я думаю, что эти анимации Lottie можно легко перестроить как виджеты Flutter.

@dnfield , отлично, вы могли бы быть парнем низкого уровня, обрабатывающим изменения на уровне движка, пока я работаю над виджетом верхнего уровня (асинхронный анализ svg, построение «изображения», которое можно кэшировать и отправлять на холст при обновлении рендеринга и т. д.).
да, работа с Лотти отлично подойдет для рабочего процесса дизайнера/разработчика.
@zoechi, зачем переделывать что-то вручную с помощью виджетов, если можно просто импортировать работающий виджет Lottie, который все сделает за вас? Сказав, что моя предыдущая цель (2) выше отлично работала бы с анимацией виджетов (поэтому я тоже хочу это сделать).

@zoechi - цель состоит в том, чтобы позволить дизайнерам создавать такие вещи и визуализировать их с минимальными усилиями со стороны разработчика. Второстепенной целью было бы позволить загружать их как ресурсы во время выполнения, а не требовать предварительной компиляции.

То же самое верно и для SVG — да, разработчик, безусловно, может преобразовать векторные данные SVG в Dart, но в идеале вы можете просто включить ресурс векторного рисунка (SVG или нет) и визуализировать его во время выполнения.

Другими словами, я хочу иметь возможность сказать моему дизайнеру создать векторный ресурс один раз и иметь возможность использовать его в моем приложении Flutter с минимальными изменениями (и без того, чтобы дизайнер экспортировал его 5 раз в различные растровые форматы, которые в конечном итоге становится недействительным, как только Apple или Samsung выпустят свой следующий телефон).

различные растровые форматы

да, это похоже на предыдущее десятилетие

https://github.com/luberda-molinet/FFImageLoading Возможно, стоит посмотреть, использует Skia для рендеринга SVG для Xamarin

@escamoteur

Спасибо, это выглядит действительно хорошо, единственное, чего не хватает, так это того, что это не асинхронно;)

В последнее время я использую только векторные рисунки в приложении для Android и не вижу заметного снижения производительности. Значки четкие, а размер приложения намного меньше. Также гораздо проще и быстрее тестировать разные изображения. Это решение @2 , @3 , @4 , @5 ,.... выглядит огромным шагом назад в таком современном фреймворке, как Flutter.
Я не понимаю, почему вы просто не можете обратиться к команде, ответственной за векторные рисунки Android, и использовать их идеи или реализацию (если возможно) для решения этой проблемы.

Я играл с некоторыми SVG, нарисованными на холсте здесь. Элементы path , вероятно, сложнее всего реализовать, но есть API Skia, который действительно поможет, если его раскрыть. Я экспериментировал с выставлением его в движке и открою PR, как только у меня будет немного больше времени, чтобы доработать его.

Грубая идея заключается в том, что мы можем создать dart:ui Path из строки данных SVG, используя для этого уже существующий API Skia. Предлагаемый метод static Path Path.parseFromSvgData(String svgData) -> Path

Это все еще оставляет некоторую работу по анализу различных преобразований/штрихов/заливок, которые можно применить. Я думаю, что мы можем позаимствовать большую часть этого из работы @amirh (я не заимствовал всю его логику синтаксического анализа пути, потому что казалось, что она может иметь ограничения, которых нет у SkParsePath, и, как SkParsePath, должен быть более эффективным, поскольку для этого потребуется только один цикл туда и обратно на исходную сторону для рисования пути, а не туда и обратно для каждой команды рисования). Я также не стал использовать @matanlurey по тем же причинам.

См. https://github.com/flutter/flutter/blob/master/dev/tools/vitool/lib/vitool.dart , https://github.com/dnfield/flutter_svg (который в настоящее время способен отображать два SVG включены в этот проект на холст) и https://github.com/dnfield/engine/tree/path_svg (который в настоящее время также включает мою работу, связанную с PathMeasure/PathMetrics для Lottie).

Привет @dnfield ,

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

У меня проблема с архитектурой, и вот почему. Чтобы пользовательский интерфейс реагировал со скоростью 60 кадров в секунду, у каждого кадра есть только ~ 16 мс для запуска перед блокировкой пользовательского интерфейса. Итак, давайте предположим, что половина используется Flutter для выполнения своих задач, что оставляет 8 мс для нашего парсера SVG, и нет никакого способа проанализировать любой файл SVG и сгенерировать изображение за этот период, независимо от того, насколько мощный у вас телефон/планшет. Поэтому лучше всего ориентироваться на медленные устройства и иметь асинхронный код, который может делать это с использованием нескольких кадров, но ключ в том, что каждый кадр может работать только до 8 мс, а затем он должен возвращаться и принимать следующий кадр.

Таким образом, вы не можете анализировать XML с помощью dart:xml , потому что он не асинхронный, он будет блокироваться до тех пор, пока не будет проанализирован весь файл. Также создание изображения должно быть асинхронным, потому что вы не можете сделать все за 8 мс. Тем не менее, нет смысла преждевременно оптимизировать код, поэтому пишите лучший код, который можно прочитать. У меня есть план, который сработает, но это займет некоторое время, поэтому я хочу, чтобы вы продолжали в том же духе, потому что я всегда могу взять вашу работу и использовать ее позже. Мой дизайн подключается к текущей функции загрузки изображений (AssetImage и NetworkImage), и пользователю просто нужно указать «.svg» вместо «.png».

Карлос.

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

@cbazza - спасибо. Я не думаю, что dart_xml — лучшее решение для этого, но оно работает и позволяет продвинуться в логике рисования (и я не хотел полностью блокировать это, работая над реализацией асинхронного синтаксического анализатора XML). Я также начал рассматривать реализацию ImageProvider , но я полагаю, что это может быть деталь реализации, которую мы можем скрыть от пользователей.

Я никоим образом не настроен ни на один из этих API. Но мы можем хотя бы начать рисовать SVG и, возможно, поддерживать простые на приличных телефонах.

Собираетесь ли вы работать над API чтения/анализа XML/SVG?

@zoechi - мы все еще могли бы добиться гораздо лучшего использования памяти и, возможно, лучшего времени синтаксического анализа с моделью потокового чтения.

@zoechi да, я смотрел на изоляты, но вы можете передавать только примитивные значения (null, num, bool, double, String), а также списки и карты, а не объекты и/или деревья объектов, поэтому асинхронный маршрут казался лучше. Еще одна интересная особенность асинхронного синтаксического анализа xml заключается в том, что концепции применимы к любой асинхронной обработке дерева, например, к виджету или дереву элементов. Это позволит асинхронное согласование, например, как в React's Fiber :)

@dnfield да, я работаю над асинхронным парсером/процессором xml/svg.

просто интересно, рендеринг SVG с использованием веб-представления может быть вариантом?

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

Я не разработчик iOS, поэтому теперь я вижу, что в iOS 11 также есть поддержка векторных ресурсов . Это не SVG, а PDF. Легче ли поддерживать векторные ресурсы PDF?

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

PDF сложнее, чем SVG, а подмножество PDF/X (используемое для векторных ресурсов) предназначено для печати. Я хотел бы видеть поддержку рендеринга PDF на Flutter, но для нас давайте придерживаться SVG.

Я был бы доволен простым подмножеством VectorDrawable svg (точка, линия, кривая, заливка, перемещение). Flutter позволяет использовать RAD и стремится быть по-настоящему мультиплатформенным (с приходом рабочего стола), но сейчас это невозможно. Платформы Android и Apple присутствуют на экранах с диагональю 60 дюймов и более 4HD. Там векторная графика обязательна.

PS Извините, но без VG ваша работа (команда по флаттеру) исчезнет, ​​потому что Kotlin изначально работает на многих платформах, включая iOS. Конечно, родной Kotlin все еще находится в бета-версии, но и Flutter тоже. :(

@ohir Пожалуйста, объясните, как бы вы написали кросс-платформенное представление (один код), которое работает как на iOS, так и на Android с нативным Kotlin. Если вы не собираетесь сделать kotlin-версию абстракции родного виджета?

Давайте не будем недооценивать то, что будут делать коренные жители Котлина, потому что возможности безграничны. Я пришел к Flutter из своих экспериментов по созданию чего-то вроде Flutter с использованием Cocos2d-x. Они могли бы использовать и это, и/или React Native, и/или Flutter, потому что все с открытым исходным кодом и доступно для перекрестного опыления :)

Да, полностью согласен, любовь и принятие kotlin разработчиками огромны, а кроссплатформенная компиляция делает возможности безграничными. Но сравнение между бета-версией Flutter и нативной бета-версией Kotlin для мобильной кросс-платформы сегодня бессмысленно.
Впрочем, отклоняясь от темы.

@lukaspili Пока что есть анко для Android. Его макеты DSL могут работать без изменений также с apko , linko и winko *, включенными в соответствующее поддерево платформы. Но это OT для проблемы Flutter VG. [* пока не существует].

Спасибо за страстный разговор! Мы хотели бы сосредоточить внимание на этом выпуске на примерах использования и требованиях к векторным форматам и API. Заранее спасибо за продолжение темы! :)

Что люди думают о разделении этого вопроса на поддержку SVG и сохранении этого для некоторого векторного формата TBD?

Это имело бы для меня смысл; исходная проблема сформулирована как какой-то векторный формат, специфичный для Flutter.

@cbazza Ура за поддержку svg. У меня есть куча svg без значков, которые я использую для рисования всего пользовательского интерфейса приложения. Как я должен отправить их вам?

Хотелось бы попробовать перейти на флаттер, но генерация миллиона png серьезно увеличит размер приложения и будет выглядеть некрасиво.

да, пожалуйста, пришлите мне URL-адрес для просмотра файлов.

Итак, на данный момент, на этом фронте, я использую подход, основанный на Flatbuffer. Я работаю над определением схемы Flatbuffer, которая могла бы захватывать команды векторного рисования — более или менее так, как Skia захватывает пути.

Я мог видеть, что это наполовину совместимо с SVG (например, есть инструмент преобразования SVG -> Flatbuffer или Android Vector Drawable XML -> Flatbuffer, который может охватывать многие варианты использования SVG), и избежать многих ударов по производительности, которые мы столкнулся бы с SVG (отсутствие потокового синтаксического анализа XML, необходимость анализировать данные пути SVG, а затем отправлять их в собственный код по крупицам). Я также смог создавать двоичные файлы меньшего размера, чем формат SVG (хотя еще неизвестно, насколько хорошо это будет масштабироваться).

Также должна быть возможность заранее указать в инструменте преобразования, какие функции не поддерживаются в данном SVG (например, «ForeignElements не поддерживаются этим форматом»).

Бит парсинга Flatbuffer может быть выполнен в Dart или C++ — единственная вещь в dart — это то, что было бы неплохо иметь какой-то способ пакетной передачи команд в Skia для построения путей и рисования на Canvas.

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

@sandrobilbeisi , вы имеете в виду https://github.com/amirh/flutter/commit/69de4bbf3177d9766a386c55b27a12619da43a05 ?

это примечательно... а еще есть vitool https://github.com/flutter/flutter/blob/master/dev/tools/vitool/lib/vitool.dart

но я больше думал как об этапе сборки, подобном тому, который Xcode использует с активами SVG для результатов iOS.

@sandrobilbeisi , вы имеете в виду создание растрового изображения из svgs во время компиляции?

Кстати, пакет Xamarin ffimageloading кэширует визуализированные растровые изображения, поэтому рендеринг выполняется только один раз. Он также кэширует сетевые изображения и изображения с измененным размером, что делает его очень быстрым.

не растровое изображение, а Skia, который изначально был движком векторной графики для < canvas >
https://skia.org/ (ps приобретено Google десять лет назад: http://www.satine.org/archives/2007/03/05/the-skia-source-code-dilemma/)

Вы имеете в виду преобразование svg в формат изображения skia?

да

Ссылка @cbazza на тестовые файлы SVG: https://github.com/slingshotapp/artwork

Есть ли способ запустить vitool на уровне проекта? Я могу создать сгенерированный файл, но ему нужен доступ к большому количеству частных классов, которые не позволяют мне добавить .g.dart в мой проект.

Ссылаясь на инструмент в <flutter>/dev/tools/vitool : #dart bin/main.dart --asset-name=_$hello --output=here.g.dart ./test_assets/horizontal_bar_relative.svg

@emilieroberts Спасибо, но эти файлы не в формате SVG, а в пользовательском векторном формате Android, который очень похож на SVG.

@cbazza упс, действительно - большинство svg сейчас там :)

@cbazza , можете ли вы уточнить, что вы имеете в виду под пользовательским вектором Android? У них есть тег <svg , в отличие от векторных рисунков Android.

То, что сейчас делается с помощью vitool, просто потрясающе, но я нигде не смог найти и следа документации. Я могу написать пример с AnimatedIcons.arrow_menu , но я также хотел бы знать, что потребуется для этого из активов из внешнего SDK флаттера.

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

Если вы хотите сгенерировать файлы с помощью vitool и использовать его в своем проекте, вы можете сделать это, скопировав код из packages/flutter/lib/src/material/animated_icons и включив его в свой проект (это также гарантирует, что ваш проект не сломается, если мы меняем технику, используемую AnimatedIcon).

Приносим извинения за неудобства и надеемся, что скоро мы получим лучшее решение.

Мне нравится эта идея, особенно если https://github.com/flutter/flutter/issues/13834 пойдет дальше. Я считаю, что такая вещь не должна быть частью монолитного SDK, но меня не особенно беспокоит, является ли это официальным пакетом или пакетом сообщества.

Существует компактный формат для подмножества svg, придуманный для Shiny (среда рабочего стола Go) кем-то из большого G. Его двоичное представление и может уменьшить размер значка запуска Android по умолчанию до 100 байт. Как указано выше в потоке - и IMSO - векторы рисования должны быть обязанностью Skia, а Flutter передает наиболее компактное доступное представление. Его инструментальная обязанность компилировать SVG-файлы res/ во внутренний формат.
[ @amirh Re: открытые вопросы о том, что было бы хорошим векторным форматом ]

Итак, FWIW, в flutter_svg я сформулировал код так, что весь рисунок действительно выполняется промежуточными объектами. Работа, связанная с SVG, в основном сопоставляет SVG с этими объектами. Предстоит еще поработать, чтобы полностью стабилизировать этот промежуточный формат (например, я начал с поддержки текста, но сейчас это очень плохо).

Я начал портировать поддержку Android Vector Drawables в фреймворк (минус поддержка внешних ссылок на цвета и стили и т. д., а также еще не поддержка путей клипа или, возможно, некоторых других функций). Должна быть вполне возможна поддержка Shiny таким же образом или любого другого формата. На данный момент мне нравится работать с SVG, потому что это помогает охватить много интересных случаев, которые нужно поддерживать, поэтому сейчас это моя основная цель.

Прочитав эту ветку — и длинную ветку о поддержке JSX — я не могу отделаться от мысли, что существует проблема управления. Команда Flutter рискует, что ее потянет в тысячу разных направлений, поскольку разработчики требуют того, что _они_ считают важным. Возможно, Flutter следует создать проекты «инкубаторов», такие как Apache. Запрошенные функции реализуются с помощью плагинов с открытым исходным кодом, возможно, при участии самой команды Flutter. Если плагины получают достаточную поддержку, эффективность и популярность, они становятся кандидатами на включение в основную структуру Flutter.

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

Я с уважением не согласен. Если вы посмотрите на вехи, такие как ведро 5, вы узнаете, над чем работает команда, а если вы перейдете в ведро 6, вы узнаете, что они считают приоритетным. Также вы можете узнать, что они не считают срочным, если посмотрите на другие вехи в будущем.

Кроме того, причина добавления чего-то в ядро ​​флаттера должна быть больше, чем «Я могу сделать плагин, и он работает для всех, и все этого хотят». Это причина для создания плагина, но этого недостаточно, чтобы добавить его в этот репозиторий или другие флаттер-репозитории.

Пример вещей, которые не должны быть плагинами: вещи, которые @dnfield добавил в движок, чтобы он мог извлечь выгоду и использовать плагин, которым он владеет. У такого плагина не было бы шансов реализовать все функции, которые он делает, если бы они не были добавлены в движок.

Быть вокалистом важно, но это никогда не гарантирует, что это пройдет. Размещение кода там, где рот, также важно, но этого недостаточно. Этот проект очень прозрачен, и они явно прислушиваются к тому, что говорят разработчики, но это не демократия и не означает, что всенародное голосование победит без размышлений о последствиях.

Да, пожалуйста, не беспокойтесь, что разработчики, работающие над фреймворком Flutter, будут отвлекаться на обсуждение ошибок. :-) Мы читаем обсуждения, и нам очень важно мнение каждого, но, в конце концов, у нас есть четкие руководящие принципы , и мы не собираемся просто реагировать на самые громкие голоса. Мы проводим тщательный анализ рынка, чтобы определить, что волнует сообщество в целом.

Интересный разговор, который оставляет меня с простым вопросом. Как команда Flutter рекомендует перейти от этапа проектирования (SVG) к векторной графике во Flutter?

@lukepighetti , вы можете попробовать https://github.com/dnfield/flutter_svg и проверить, как далеко это вас заведет.

Лично меня не устраивает решение, предлагаемое для файлов SVG во Flutter. Я использовал пакет flutter_svg, и он меня не устраивает.

На мой взгляд, поддержка SVG должна поддерживаться изначально в стандартной библиотеке. Если мы собираемся начать использовать Flutter на больших экранах, таких как настольные приложения и веб-сайты, это необходимо.

@socialmammoth , не могли бы вы уточнить, какие недостатки вы видите?

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

Однако у него есть некоторые интересные свойства — в частности, можно заставить Chrome/Chromium сгенерировать SKP (возможно, отрендеренный SVG), и весьма вероятно, что мы уже поддерживаем большинство или все команды рисования Skia, необходимые для фактического визуализировать подавляющее большинство SKP.

Я планировал создать решение типа code-gen для плагина SVG, чтобы вы могли генерировать код Dart/Flutter из SVG. Я думаю, что на данный момент, вероятно, было бы более интересно исследовать процесс сборки SKP для Dart — часть кода, написанного для Flutter SVG, может быть перенесена в фреймворк (например, RawPicture и связанная с ним инфраструктура, которая примерно соответствует RawImage ), и мы могли бы подключить что-то, что будет принимать вывод SKP (возможно, сгенерированный из SVG, отображаемый Chrome, что в любом случае является золотым стандартом для рендеринга SVG). Должна быть возможность создать инструменты, которые будут принимать SVG, вызывать безголовый Chromium для его рендеринга в SKP, а затем преобразовывать SKP в некоторые файлы Dart, которые Flutter может отображать во время выполнения.

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

Я также говорю это с верой в то, что на данный момент мы никогда не получим «родную» поддержку SVG во Flutter. Отчасти это связано с тем, что сам SVG имеет много багажа (XML, CSS, возможность извлечения внешних ресурсов), которые нетривиально реализовать вне браузера/ПО для рендеринга HTML и сильно раздули бы программное обеспечение, которое мы пытаемся наклониться. Это также отчасти потому, что вполне возможно реализовать довольно много SVG без внесения каких-либо значительных изменений в структуру, хотя некоторые вещи (в частности, filterEffect s и textPath s прямо сейчас), вероятно, будут Выгода от некоторых дополнительных настроек двигателя.

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

Наличие векторного формата, специфичного для Flutter, похоже на то, что Android делает с VectorDrawables, что, хотя он работает нормально, также означает, что он не может извлечь выгоду из множества инструментов, которые уже существуют для SVG. Это также затрудняет итерацию дизайна из-за всех преобразований формата.

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

@dnfield

Формат .skp (SKIAPICT).

ИМХО интересный подход. Но тогда инструменты Flutter (по крайней мере, в AS) должны беспрепятственно справляться с преобразованием. Дизайнеры несколько привыкли к ограничениям, налагаемым текущим импортом векторных рисунков Android, поэтому они наверняка смогут иметь дело с другим набором правил и запретов.

Для случайного разработчика руководство должно гласить: « Перетащите свои рисунки svg сюда, аннотируйте здесь, используйте по желанию. Если ваш svg не соответствует поддерживаемому подмножеству SVG (см. здесь), компилятор или анализатор ( flutter analyze ) сообщит что не так в вашем svg ». Или что-то вроде того.

@dnfield

заставить Chrome/Chromium генерировать

Хорошо для PoC и тестирования, но реальное решение, ИМХО, может не требовать такой огромной зависимости - и такую, которую трудно написать как промежуточный этап CI. Конечно, в бета-версии, а затем в качестве второго «сложного пути» это может быть нормально - например. чтобы получить простой анимированный рисунок, который позволяет skPicture. Я могу ошибаться. поскольку у дизайнеров обычно есть большое ведро с браузерами под клапаном ноутбука. Тем не менее, имейте в виду, что произведения искусства часто мутируют. Не только на этапе прототипирования, но и по мере приближения времени запуска, когда разработчики находятся в лихорадочном поиске ошибок.

[То есть. Нам либо нужны инструменты флаттера для совместимого импорта svg, либо нам нужен способ, при котором хром полностью находится в руках дизайнера. Не разработчика.]

PS. Путь пакета launcher_icons может выполняться при запуске: flutter packages pub run flutter_svg_to_skp:main -i path/to/svgs -o path/to/skps .

-- мой ¢2

@cachapa

возможность загружать SVG напрямую из сети

Это работа для отдельного огромного пакета, который будет заниматься валидацией и обходными путями.
вокруг возможных несовместимостей и причуд производителя.
Сначала заставьте движок рисовать предоставленный разработчиком векторный формат, который наверняка будет использовать пакет «Загрузить SVG из сети». :)

Просто для ясности @cachapa и @ohir — flutter_svg _уже_ поддерживает загрузку SVG по сети ( SvgPicture.network ). Однако этот пакет никогда не будет поддерживать всю спецификацию SVG — на самом деле цель состоит только в том, чтобы поддерживать достаточную часть спецификации для рендеринга большинства SVG. Он уже делает это, с основными исключениями на данный момент: fliterEffect s (поэтому нет размытия, цветных фильтров и т. д.) и много поддержки, связанной с текстом, но есть и некоторые другие ( marker s не поддерживаются, certian типы ссылок xlink:href по-прежнему не поддерживаются). Есть также некоторые вопросы, которые я намеренно не поддерживаю, такие как полная спецификация CSS, сценарии и интерактивность.

@lukepighetti Я думаю, что ожидания действительно существуют только у веб-разработчиков интерфейсов. Qt поддерживает SVG, но только ограниченное подмножество. GNOME поддерживает немного больше с librsvg, но опять же, у него есть некоторые проблемы (и его действительно сложно использовать вне среды Linux). Я рад видеть, что происходит с resvg, но я не знаю ни одной библиотеки с графическим интерфейсом, которая бы его интегрировала.

@dnfield Я не хочу критиковать вашу работу, так как вы проделали отличную работу, и я вам очень благодарен за это. Я просто разочарован тем, что цвет не работает, как ожидалось. Пришлось выбирать свой цвет, я не художник, я тоже дальтоник.

Flutter должен поддерживать SVG так же, как это делают современные браузеры. Это обязательно. Нам нужна возможность использовать ресурсы, скопированные или импортированные непосредственно с веб-страницы без изменений.

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

Нам нужна полная поддержка спецификаций для SVG. Я согласен с @lukepighetti . С Hummingbird это обязательно, иначе веб-разработчики посмеются над Flutter и дадут ему жесткий пропуск.

Даже @yjbanov упоминает об этом в своей статье здесь: https://medium.com/flutter-io/hummingbird-building-flutter-for-the-web-e687c2a023a8 .

Поскольку @dnfield упомянул «resvg», @SocialMammoth , возможно, flutter_svg также должен стремиться к поддержке «SVG static» вместо полной поддержки svg:
http://www.w3.org/TR/SVG11/feature#SVG — статический,
что, я думаю, должно сделать всех счастливыми.

Даже Chrome не поддерживает все функции SVG, и особенно рендеринг текста справа налево содержит ошибки (без какого-либо прогресса за последние несколько лет). Другими словами, я не думаю, что полная поддержка SVG реалистична. SVG-static кажется разумным подмножеством. В flutter_svg мне не хватает обработки текста (включая текст на пути), фильтров и масок. Было бы неплохо иметь поддержку во Flutter для создания чего-то подобного https://drifted.in/horologium-app/

@SocialMammoth

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

Нет. Приложения Flutter должны быть компактными. Эта проблема не касается всемогущего пакета для работы со всеми SVG, в нем прямо говорится «поддерживать векторный формат рисования» (не поддерживать SVG ). Насколько я понимаю, цель на данный момент состоит в том, чтобы максимально избавиться от растровых ресурсов во всех флаттер-приложениях. И это на уровне двигателя. @dnfield проделал отличную работу с пакетом. Теперь пришло время просто получить некоторую векторную графику, доступную в Dart , не раздувая движок flutter (skia) или само приложение . Использование .skp кажется хорошим выбором для этой цели. Он уже позволяет больше, чем векторный рисунок Android, и он уже есть в движке. Дизайнеры приспособятся к его набору функций.

@ohir Думаю, тогда мы не согласны. Внешний фреймворк, который не поддерживает файлы SVG, на самом деле плохая шутка.

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

По сути, SVG является стандартным векторным форматом для использования здесь, но мы не можем ожидать поддержки всех функций SVG. Целью всегда была поддержка минимума для импорта векторных ресурсов из типичных приложений векторной графики. Какие приложения векторной графики могут читать и писать .skp ?

Мой тест на достаточно распространенность векторного формата заключается в том, доступен ли он в Adobe Illustrator, Affinity Designer и Inkscape. Насколько я знаю, это в значительной степени оставляет SVG. И я согласен с тем, что нам не нужны все функции SVG. Просто основные контуры штрихов и заливок в порядке.

Я не могу утверждать это авторитетно, но я подозреваю, что было бы проще реализовать подмножество SVG, чем убедить приложения векторной графики поддерживать .skp ?

@lukepighetti : идея Дэна состоит в том, чтобы использовать внутренний формат движка. Суть этого решения заключается в преобразовании SVG в формат, понятный движку. Не имеет значения, знает ли Inkscape этот формат, пока существует какой-либо жизнеспособный конвертер.

Вчера я сомневался, но сегодня, после небольшого исследования, мне кажется, что автоматизация хрома хорошо поддерживается. Если безголовый хром можно использовать с прокси-сервером рендеринга , его также можно сделать конвертером svg->skp . Немного тяжеловат, но доступен. Действительно низко висящие фрукты, @dnfield :).

Все это прекрасно согласуется с целями, поставленными @Hixie почти три года назад.

@dnfield, пожалуйста, поправьте меня, если я ошибаюсь.
Я предполагаю, что .skp в основном является двоичным форматом для Skia Picture.

Учитывая, что у dart:ui также есть обертка для Skia Picture, которая может быть сгенерирована из Dart Land, не будет ли содержимое этих картинок содержать другие возможности Skia? По сути, один из Chrome будет использовать все функции Skia, а один из dart: ui — нет (ограничено тем, что было доступно через движок Flutter)? Немного странно для аргумента «производительность», не так ли? Flutter engine & dart:ui удаляет все Skia, которые считались медленными (без отображения показателей производительности), но затем вы можете использовать все это, если оно поступает через сгенерированный Chrome файл .skp ?

Другое дело, при использовании .skp как бы вы указали цвета значка, если, например, значок использует 2 цвета или более?

Как насчет старого аргумента, что, используя Dart во Flutter, вы контролируете каждый пиксель? Для меня пакет flutter_svg с поддержкой «svg static» — это то, что нужно, потому что он обеспечит будущие инновации в стране дартс. Если обойти Dart и просто позволить C++ справиться с этим, кажется, что Dart не сможет его взломать.

Skia, кажется, поддерживает SVG. Почему Flutter не поддерживает SVG напрямую?

Насколько я могу судить, команда Flutter хочет, чтобы размер пакета Skia был как можно меньше. Я не знал, что Skia поддерживает SVG, но если да, то это маловероятно. В качестве примечания: есть еще одна проблема с добавлением поддержки Lottie для Flutter, поскольку ее поддерживает Skia.

Skia не поддерживает импорт рисунков из SVG, но имеет некоторую экспериментальную поддержку для создания SVG (что здесь не так полезно).

И да, размер упаковки вызывает беспокойство.

Пожалуйста, если вы хотите запросить поддержку SVG, см. https://github.com/flutter/flutter/issues/15501 .

Эта ошибка связана именно с поддержкой векторной графики без поддержки SVG.

Для людей, которые интересуются форматом векторной графики, мне любопытны ваши варианты использования.

Я знаю о них до сих пор:

• Иконки. Статические изображения, которые могут нуждаться в динамическом перекрашивании (например, становятся серыми при отключении) и могут нуждаться в различных уровнях детализации в зависимости от размера целевого рендеринга. Вряд ли будет текст.

• Анимированные значки: два значка, как описано выше, и описание плавного перехода от одного к другому.

• Фоны: изображения, которые могут быть намного больше экрана, могут отображаться с параллаксом; как правило, простые сцены с формами, градиентами и тенями, которые вряд ли будут иметь текст.

Есть ли другие варианты использования, которые мотивируют вашу потребность в векторной графике? Пожалуйста, опишите их здесь. Спасибо.

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

Мое приложение в основном является компаньоном для конференции. Я хочу включить карты отеля с возможностью панорамирования и масштабирования. Использование растра высокого разрешения нецелесообразно по причинам размера и производительности; векторная графика идеальна.

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

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

Чтобы добавить к тому, что сказал Дэн: всего 1 КБ векторного исходного кода может обеспечить четкую детализацию, плавное изображение как на 7-дюймовом планшете, так и на 105-дюймовом 4HD-телевизоре. Недавний кейс из кассы Киоск-приложение для экранов 10 или 14 дюймов (лицом к кассе) и 5 ​​или 7 дюймов (лицом покупателя). Набор из 5000+ векторных рисунков вкусностей весил менее 5 МБ. Только подмножество «овощей» (~ 150) из него, преобразованное в PNG для двух используемых экранов, составляло более 30 МБ. Полный набор ресурсов может заканчиваться диапазоном ГБ.

PS Следующим важным шагом будет создание векторной графики с определенными сенсорными областями, например, с помощью выбранной заливки. Это позволило бы сэкономить тысячи строк кода для всего класса в основном статических, но богатых деталями интерфейсов.
Как в интерактивных руководствах по эксплуатации машин.

Мечты в сторону - просто дайте нашим дизайнерам сначала использовать простые векторные рисунки :)

Спасибо за обратную связь. Очень полезно.

@ohir Можете ли вы уточнить «повернуть, перекосить или расплавить»?

Мой обходной путь для этого, которым я действительно очень доволен, заключается в использовании пакета path_parsing (https://pub.dev/packages/path_parsing) для создания команд рисования холста из строки пути SVG, а затем с использованием этих чтобы сделать виджет CustomPainter , который его рисует. Для других фигур SVG, помимо контуров (прямоугольник, круг и т. д.), я просто вручную перевожу их в команды рисования, что немного утомительно, но не слишком сложно.

Это очень хорошо работает для простых векторных значков и позволяет использовать один и тот же виджет разных размеров и цветов во всем приложении.

Вот код: https://gist.github.com/jpotterm/7b30739e0af722baf97a397d9841d908

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

@Хикси
Например. https://dribbble.com/shots/1083175-Контроллер кондиционера#
Центральную вращающуюся ручку и датчик вокруг нее можно тщательно нарисовать с помощью текущего Canvas API, но он также может уместиться в 2 КБ (xml svg), а затем около 300-500 байт. Если бы векторная графика и рудиментарные аффинные преобразования уровня Skia были доступны через какой-нибудь интерфейс «векторной графики», эту ручку можно было бы оживить, просто применяя заливки к сегментам датчика и вращая траекторию маленького круга индикатора.

Более важно, чтобы вся эта ручка, с цветами и другими деталями, была нарисована именно так, как задумал дизайнер, потому что вся ее работа будет просто встроена. Интерфейс векторных рисунков + заливка + градиенты + хороший дизайнер может выглядеть так: https://www.artua.com/app-design-deckadance/
Аффинные преобразования со стороны разработчика сделают такой дизайн отзывчивым и ярким.
Что касается косых и сдвиговых преобразований: можно, например. использоваться для моделирования переключения рычага управления.
(«Расплавление», вероятно, вызвано призраком Сальвадора Дали;)

/не по теме/

@jpotterm
Было бы очень полезно, если бы существовал официальный инструмент командной строки для флаттера, который анализировал файл SVG и создавал команды рисования холста, которые давали бы аналогичный результат.

Я произвел что-то подобное. Генератор кода, который ищет аннотацию, берет указанный SVG PathData и создает геттер, возвращающий объект Path. Если люди захотят, я могу очистить его и открыть исходный код.

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

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

Спасибо всем за ваши отзывы. Очень полезные комментарии.

Для людей, которые интересуются форматом векторной графики, мне любопытны ваши варианты использования.

Другой вариант использования — это все, что требует динамической графики:

• графики
• загрузочные стержни
• Рисование
• и т.д

На самом деле я очень удивлен, что Flutter не поддерживает это, поскольку Skia поддерживает подмножество SVG (в любом случае полезные части).

Я хотел бы использовать SVG для искусства. Качественный полноэкранный формат PNG для планшета может иметь размер 2 МБ и более, а его эквивалент SVG — 5–10 КБ. Добавьте несколько экранов, и мы говорим о 20 МБ в пакете вместо 100 КБ.

Для программной графики я большой поклонник CustomPaint, поэтому я бы никогда не использовал SVG для таких вещей, как диаграммы, полосы загрузки, рисование и т. д. Для тех, кого беспокоит CustomPaint API, ментально это очень похоже на HTML Canvas API. И да, хотя я согласен с тем, что писать что-то в CustomPaint дорого, в итоге вы получаете прочную основу, рендеринг очень быстрый и очень красивый.

Если вы собираетесь поддерживать SVG, вы должны поддерживать все функции SVG, такие как градиенты, штрихи и многое другое. Этого не было сделано в проекте Android, и это вызывает некоторые предупреждения у разработчиков, поскольку почти все остальные dev. платформы поддерживают SVG и векторы. Это основы графики, делайте это правильно!

@harounhajem см. https://github.com/flutter/flutter/issues/15501 для этой темы, а также https://github.com/dnfield/flutter_svg

@PierBover для диаграмм, в частности, рассмотрите https://pub.dev/packages/charts_flutter

Я только что прыгнул во Флаттер. Я занимался рефакторингом личного приложения с Ionic 3 на Ionic 4, и оно (опять же) было совершенно другим, и для этого требовалось приложение с нуля.
Поэтому я решил перейти на Flutter и попробовать. Как я уже сказал, это приложение было закончено и работало, и оно включает в себя множество графики и значков, которые были готовы в моем приложении. Я не дизайнер, и мне нужно платить за этот дизайн.
Я понимаю, что я не единственный, кто в этой ситуации хочет повторно использовать свои активы SVG.

@erperejildo - см. https://pub.dev/packages/flutter_svg

(не уверен, почему это не закрыто тогда)

Потому что актуальная проблема — поддержка векторного формата рисования, отличного от SVG, — не решена?

о, моя вина @jonahgreenthal. Я пришел сюда в поисках поддержки SVG и увидел, что третий комментарий просил то же самое.

Uber сделал это для iOS: https://github.com/uber/cyborg .
Было бы интересно увидеть что-то подобное во Flutter.

Есть новости по этому поводу?

@dnfield отлично работал, отображая svg как новый виджет, но не работает со свойством AssetImage . Мне нужно отобразить его с помощью виджета CircleAvatar

@Hixie , есть также вариант использования, когда значок svg должен иметь несколько цветов, поскольку это помогает пользователю понять значение значка. Поэтому я надеюсь, что решение будет включать в себя возможность настраивать цвет темы.

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

4 года различных комментариев без какого-либо полезного решения. Короче - нет, нельзя. Нет, не планируется.

Можем ли мы хотя бы узнать, почему это так проблематично/сложно?

Flutter_svg имеет достойную поддержку SVG во флаттере. Rive также поддерживает векторный формат для флаттера.

Эта проблема касается создания нового векторного формата. Это требует времени :)

@dnfield есть некоторые виджеты со свойствами фона, которые мы не можем передать svgs. Есть ли способ заархивировать это?

пожалуйста, добавьте правильную поддержку svg вместо создания нового формата. Svg является стандартом де-факто.

Всякий раз, когда я создаю приложение, обычно есть связанный веб-сайт, а веб-сайты используют svg, и они используют красиво анимированные svg, которые легкие и красивые при любом разрешении.
Было бы действительно разумно просто повторно использовать эти анимированные svg во Flutter, чтобы можно было должным образом достичь согласованности, вместо того, чтобы повторно реализовывать изображения и анимацию!

SVG уже существует, работает и широко используется и поддерживается везде. Сосредоточьтесь на том, что нам нужно.

Эта проблема касается создания нового векторного формата.

То есть, вы имеете в виду, что этот вопрос об изобретении велосипеда, верно? Я согласен с @d-silveira - лучше добавить встроенную правильную поддержку svg, нам не нужен новый векторный формат.

Да, речь идет об изобретении лучшего колеса. SVG уже поддерживается во Flutter с помощью flutter_svg.

Лучше иметь возможность импортировать svg и обрабатывать их внутри, либо во время сборки, либо автоматически генерировать код во время импорта. Подобно родному Android — вы можете импортировать svg, и определение пути Android xml будет сгенерировано из исходного svg. Импорт в проект Flutter может генерировать код дротика для повторного использования для рисования векторного актива.

@Hixie хорош для улучшения ситуации, я не буду обсуждать это, но как мы можем пока поддерживать некоторые виджеты, которые разрешают только изображения, отличные от svg? (например, те, у которых есть фоновые свойства)

Это будет запрос функции для flutter_svg.

@Hixie Flutter SVG может создать там изображение, но было бы неплохо, если бы в некоторых случаях фреймворк был более терпимым к съемке изображений, а не изображений. Подано https://github.com/flutter/flutter/issues/49712

флаттер_svg

Это почему? Это никак не связано с пакетом flutter_svg :

CircleAvatar(
  backgroundImage: MySVGImage(),
)

@Hixie flutter_svg будет работать только в некоторых случаях. Позвольте мне привести вам практический пример: мне нужно использовать REST API, который в некоторых из его конечных точек возвращает URL-адреса изображений. Изображения создаются пользователем в бэк-офисе, поэтому некоторые из них имеют формат png, некоторые — jpg, а некоторые — svg. Бэк-офис не включает расширение файла в URL-адрес и не поддерживает HEAD, поэтому у нас нет возможности заранее узнать тип изображения.
Ожидаемое поведение флаттера будет заключаться в том, чтобы получить URL-адрес в image.network и обработать его, вместо того, чтобы заставлять меня прыгать через обручи, чтобы угадать, какой это тип изображения, и если это svg, переключиться на flutter_svg.
Все это даже не принимает во внимание тот факт, что flutter_svg не всегда является заменой изображения! :п

SVG в целом будет работать только для некоторых случаев использования. :-)

Эта конкретная проблема связана с форматом векторной графики, отличным от SVG. Если у вас есть другое требование, я рекомендую зарегистрировать его как отдельную проблему.

Из предыдущего обсуждения некоторые важные соображения заключаются в следующем:

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

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

Может быть, ребята из Rive смогут собрать какую-нибудь библиотеку для преобразования SVG. У них уже есть проприетарный (с открытым исходным кодом) векторный движок для Flutter. @луиджи-россо

Почему бы не добавить поддержку импорта svg в проект Flutter. И конвертировать в код дротика/новый векторный рисунок и т. д. Обратите внимание, что та же ситуация и на родном Android, поэтому мы не используем svg напрямую (что, я согласен, не имеет большого смысла) и вместо этого импортируем в проект, svg удаляется из не поддерживаются и не нужны функциональные возможности и преобразованы в определение пути Android.

Разве это не хорошая идея для Флаттера?

@ giaur500 Эта проблема не об этом. Если у вас есть предложения конкретно по SVG, пожалуйста, отправьте отдельный вопрос.

Справедливости ради следует отметить, что во многих комментариях в этом выпуске обсуждаются SVG и Flutter.

следить

SVG идеально подходит для отличного пользовательского интерфейса на уровне пикселей. На данный момент лучший для отличных пикселей.

@lukepighetti Да. К сожалению, все они не по теме, и их наличие здесь не приведет к каким-либо улучшениям Flutter.

Из предыдущего обсуждения некоторые важные соображения заключаются в следующем:

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

Инструмент времени сборки был бы отличным, взял бы вектор и визуализировал все плотности экрана и добавил активы в виде изображений. Apple iOS делает это с помощью значков PDF.

Лучше иметь возможность импортировать svg и обрабатывать их внутри, либо во время сборки, либо автоматически генерировать код во время импорта. Подобно родному Android — вы можете импортировать svg, и определение пути Android xml будет сгенерировано из исходного svg. Импорт в проект Flutter может генерировать код дротика для повторного использования для рисования векторного актива.

мне это нравится

@ giaur500 Эта проблема не об этом. Если у вас есть предложения конкретно по SVG, пожалуйста, отправьте отдельный вопрос.

Создан новый выпуск: https://github.com/flutter/flutter/issues/63752

Так каково это состояние?
Есть ли намерение вообще поддерживать что-то похожее на VectorDrawable или даже сам VectorDrawable для Android?

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

Я никогда не пробовал это сам, но флаттер svg lib имел поддержку at
наименьшие ключевые особенности векторных рисунков, таких как пути.

В сб, 15 августа 2020 г., 19:46 n00bmind, уведомления@github.com написал:

Так каково это состояние?
Есть ли вообще намерение поддерживать что-то похожее на
VectorDrawable или даже сам VectorDrawable для Android?

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

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/flutter/flutter/issues/1831#issuecomment-674375846 ,
или отписаться
https://github.com/notifications/unsubscribe-auth/ABI4Y4LWYSYEIWI3RRSSCK3SAZKO5ANCNFSM4B3FXMMQ
.

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

Есть ли причина, по которой у вас не работает пакет flutter svg? Мы используем его с большим успехом в одном из наших приложений. Я никогда не использовал Vector Drawable, поэтому я не уверен, как он сравнивается с SVG.

Кажется, пакет flutter_svg стоит посмотреть для такого варианта использования.
@lukepighetti , как бы вы оценили его работу? Мое использование было бы просто изображением-заставкой и несколькими изображениями размером с иконку здесь и там в приложении, так что ничего особенного.

Кажется, пакет flutter_svg стоит посмотреть для такого варианта использования.

@lukepighetti , как бы вы оценили его работу? Мое использование было бы просто изображением-заставкой и несколькими изображениями размером с иконку здесь и там в приложении, так что ничего особенного.

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

@лукепигетти

прежде чем они окажут давление на флаттер-команду, чтобы она сделала что-то внутри.

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

Я думаю, что людям действительно стоит попробовать _(svg package)_

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

[@Хикси]

Если я что-то не упустил, реализация такой функции флаттера будет очень похожа на пакет @dnfield flutter_svg , который, по-видимому, решает описанный вами вариант использования. Кроме того, сопровождающий входит в основную команду Flutter, поэтому мы можем быть уверены в его качестве. Вам было бы лучше, если бы этот пакет был в https://github.com/flutter/plugins ?

Если есть что-то, что мне не хватает, пожалуйста, не стесняйтесь просветить меня, чтобы я мог узнать больше об этой теме.

@лукепигетти

Я думаю, что "не SVG" в названии номера нужно сделать красным, жирным и мигающим.

Эта проблема конкретно не о формате svg.

OP (и я) надеялись раскрыть API пути Skia, чтобы графика ресурсов могла быть представлена ​​​​в компактной форме, то есть в двоичном формате с фиксированным порядком байтов. Дэн даже сделал патч для Skia , который работает с flutter_svg, что, в свою очередь, теперь позволяет нам использовать ресурсы svg. Хотя по-прежнему мы анализируем xml во время выполнения приложения и рисуем, вызывая движок — также для статических ресурсов, входящих в состав apk.

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

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

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

Как бы там ни было, в использовании flutter_svg нет ничего плохого, просто ему не хватает даже некоторых очень простых вещей, например, он не поддерживает проценты и прямо вылетает при попытке их рендеринга. Этот комментарий не является ударом по библиотеке flutter_svg, он просто объясняет людям, которые говорят, что мы можем просто использовать flutter_svg.

Кажется, что flutter_svg работает очень хорошо, несмотря на отсутствие поддержки сценариев, HTML, SMIL и т. д.

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