Autres pensées aléatoires (pas toutes les miennes):

• Nous voulons vraiment éviter de prendre en charge un format où il existe une attente préexistante d'implémentation de fonctionnalités qui ne seront pas performantes. Par exemple, la mise en œuvre de SVG amènera les gens à s'attendre à une prise en charge complète de SVG, y compris les scripts, HTML, SMIL, etc.
• Nous devrions concevoir notre format explicitement très étroitement aligné sur les fonctionnalités de performance de Skia, par exemple drawAtlas.

La prise en charge des vecteurs semble cruciale pour un framework d'application prenant en charge différentes tailles et densités d'écran. Sinon, vous vous retrouvez avec des icônes qui ressemblent à ceci :

Au lieu de cela:

@HansMuller

Kris l'a également mentionné : nous pourrions effectuer un traitement SVG limité au moment de la construction. Par exemple, nous pourrions générer des widgets d'icône MD basés sur les descriptions SVG. Si cela est fait avec soin, cela pourrait économiser de l'espace et augmenter la fidélité aux conceptions originales.

Pour les icônes de conception de matériaux en particulier, nous devrions étudier l'utilisation de la police d'icônes de conception de matériaux.

@appsforartists Pour ce que ça vaut, ni Cocoa ni android.view n'utilisent des formats vectoriels pour les icônes.

@abarth ne me surprend pas à propos d'iOS - il semble qu'ils aient commencé avec un écran de 3,5 pouces codé en dur et qu'ils se soient efforcés de conserver ce modèle mental/simplicité des résolutions prises en charge depuis (voir : la largeur de chaque iPhone étant la même, ou l'iPad et l'iPad mini d'origine ayant la même résolution).Je ne connais pas grand-chose au développement mobile, mais c'est un peu surprenant qu'Android ne soit pas basé sur le vecteur.

Dans tous les cas, les icônes ne doivent pas ressembler à des alias comme dans la capture d'écran ci-dessus, et les vecteurs sont une bonne solution pour l'indépendance de la résolution. La façon dont vous choisissez de mettre en œuvre pour résoudre de jolies icônes dépend de vous. :smiley:

La façon dont vous choisissez de mettre en œuvre pour résoudre de jolies icônes dépend de vous.

Seriez-vous prêt à déposer un problème distinct concernant le problème de résolution que vous rencontriez avec les icônes ? @krisgiesing a implémenté un résolveur d'actifs prenant en charge la résolution qui gère de nombreux cas. Il serait utile de connaître les cas qu'il ne traite pas.

J'envisage d'ajouter des tests pour la prise en charge actuelle de la sensibilité à la résolution, ce serait donc le moment idéal pour comprendre si quelque chose ne fonctionne pas correctement.

Il semble que le 3x ait un ratio de pixels d'appareil de 2.6 , pour lequel nous n'avons probablement pas d'actif.

Je regarde ce cas précis maintenant. Le rapport de pixels de l'appareil est de 2,625 ; nous choisissons l'actif 3.0x, ce qui est attendu. Cependant, quelque chose semble se passer pendant le rendu qui provoque une sorte d'artefacts de crénelage supplémentaires. Ainsi, bien que @abarth ait corrigé le cas des icônes Material Design en passant à une police, j'enquête toujours au nom d'autres types d'actifs d'image qui nécessitent une mise à l'échelle dépendante de la résolution.

J'ouvrirai un autre bogue pour suivre cela car il est tangentiel à la prise en charge d'un format vectoriel.

Voir #2337

Android prend en charge le format "VectorDrawable" qui n'est qu'un sous-ensemble performant de SVG. J'espère que vous envisagez d'utiliser le même format, étant donné qu'il bénéficie déjà d'un certain support communautaire et que l'équipe Android a apparemment jugé ses performances adéquates.

VectorDrawable est certainement influencé par SVG mais ce n'est pas un sous-ensemble. De plus, il utilise XML, ce qui garantit à peu près que ce ne sera pas le format vectoriel le plus performant que l'on puisse trouver. :-)

Il était faux de décrire VectorDrawable comme un sous-ensemble strict, mais cela semble toujours être un compromis équilibré entre la garantie de bonnes performances de rendu et la facilité d'utilisation. La spécification VectorDrawable s'en remet fréquemment à la spécification SVG pour des domaines clés tels que la syntaxe des données de chemin, ce qui facilite grandement la conversion des actifs SVG que de nombreux développeurs utilisent déjà et partagent les VectorDrawables que les applications Android existantes contiennent déjà.

Je ne peux pas imaginer que XML est un bloqueur de performances important car il n'affecte que l'analyse. Il me semble que les performances _render_ - le type de performances qui affectent l'objectif de Flutter des applications 60fps - dépendent davantage de l'ensemble des opérations vectorielles que Skia devra dessiner, et non d'une étape d'analyse qui peut être effectuée une fois et mise en cache.

Je ne veux pas insister sur ce point, mais je ne peux pas m'empêcher de penser que le travail pour cela a déjà été fait et n'a donc pas besoin d'être mis de côté dans le jalon "après la version 2.0".

Nous avons fini par utiliser la police Material Design pour les icônes Material Design. Je ne connais aucun obstacle empêchant quelqu'un de construire cela sur Flutter aujourd'hui en utilisant des appels directs dart:ui ou un widget CustomPaint : https://docs.flutter.io/flutter/widgets/CustomPaint-class. html. Nous n'avons pas de plans immédiats pour en construire un pour le moment.

$.02 - même les navigateurs janky ( et le framework concurrent React Native peu importe, leur solution est hacky) peuvent rendre SVG. L'option d'exportation d'image nécessite la création d'un minimum de 3 fichiers pour chaque icône ou ressource artistique pour mon équipe. C'est une mauvaise pratique par rapport à un fichier SVG qui peut être affiché à n'importe quelle résolution.

Pour le commentaire ci-dessus de Hixie, les attentes préexistantes ne devraient pas empêcher la mise en œuvre d'une fonctionnalité intéressante. Je préférerais de loin pouvoir bénéficier d'un support de base pour l'affichage SVG (ce qui résout de nombreux problèmes pour moi et mon équipe) et découvrir que les options étendues ne sont pas disponibles plutôt que de compter sur un nombre toujours croissant de PNG pour s'adapter au nombre toujours croissant nombre de résolutions d'écran.

Je me rabats sur la création d'une police pour mon équipe, mais ce n'est pas aussi bon que le support SVG natif, car le format de police ajoute une mise en forme supplémentaire pour la hauteur de ligne et l'espacement des lettres qui doivent être ajustés dans l'application. De plus, les polices veulent être affichées à des résolutions fixes (12px, 16px, 20px, 36px...) ce qui est également limitant.

Merci pour le cadre Flutter cool. :)

J'encourage tous ceux qui souhaitent la prise en charge de SVG à implémenter la prise en charge de SVG en tant que package Dart pour Flutter.

Pour ceux que cela intéresse, je signalerais https://docs.flutter.io/flutter/dart-ui/dart-ui-library.html qui est la bibliothèque de bas niveau pour le dessin.

De l'équipe : La bibliothèque Dart n'est pas une solution assez bonne. Il suffit de le transmettre.

Pourriez-vous préciser ceci? L'ensemble du framework Flutter est une bibliothèque Dart ; tout ce que nous implémenterons ici sera probablement une bibliothèque Dart. Quelles sont les exigences pour "assez bien" ?

Par exemple, j'ai implémenté un analyseur SVG (simple, non exhaustif) dans pure-Dart il y a quelque temps :

https://github.com/matanlurey/svg

Il serait probablement quelque peu trivial de :

une. Créez un SVG d'exécution -> SvgRenderElement , qui utilise dart:ui sous le capot.
b. Créez une étape de compilation au moment de la construction qui convertit un SVG en quelque chose comme :

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

@deborah-ufw si vous êtes intéressé, nous serions ravis de discuter pour en savoir plus. Pouvez-vous m'envoyer un e-mail ?

Salut Seth, matanlurey et Hixie - merci beaucoup pour la réponse. Je ne suis probablement pas la bonne personne à qui parler en profondeur, car ce sont nos ingénieurs principaux qui ont rejeté la solution de plug-in Dart (conduisant ainsi à la génération d'une énorme bibliothèque de png pour notre application, ce qui fait grincer des dents également la plupart d'entre nous).

Je voudrais leur transmettre le lien de ce problème Github et leur demander de contribuer aux raisons techniques de leur commentaire (qui a été fait de manière un peu plus colorée que je ne l'ai transmis) - je le ferai dès que j'aurai fini de taper.

Ils peuvent également discuter avec nos ingénieurs directement via http://gitter.im/flutter/flutter ainsi que d'autres méthodes de contact répertoriées https://flutter.io/support/ si nécessaire. :)

Je vais l'ajouter. Merci ! :RÉ

Une autre approche consiste à intégrer quelque chose comme http://svgpp.org/ au niveau natif et à utiliser le système de plug-in Flutter pour communiquer avec lui. Cela vous donnerait probablement les meilleures caractéristiques de taille/performance pour une prise en charge complète de SVG, mais au détriment du maintien d'une dépendance.

Qu'en est-il de la recherche d'un support SVG au niveau du moteur ? Je ne pense pas qu'il soit raisonnable ou souhaitable de s'attendre à une prise en charge complète de la norme, mais une partie de l'attrait réside dans la prise en charge des équipes interfonctionnelles et des outils existants.

J'ai eu l'impression que Skia fournit un support SVG de base. N'y a-t-il aucun moyen de mettre cela à la disposition de Flutter ?

D'après ce que je peux dire, cela n'a été qu'expérimental et partiel. Il y a un problème ouvert ici https://bugs.chromium.org/p/skia/issues/detail?id=5596 bit il a plus d'un an. Ils l'énumèrent également dans leur feuille de route, mais encore une fois, ils ne savent pas quelle priorité.

Cela n'aurait aucun sens de prendre en charge SVG au niveau du moteur, car cela n'exposerait pas le modèle de document SVG, qui est au cœur de la prise en charge de SVG.

Si Flutter prend en charge SVG, ce sera dans le but ultime de réellement prendre en charge le vrai SVG. C'est contre la philosophie de Flutter d'avoir des implémentations de fonctionnalités sans enthousiasme.

Je ne vois pas l'exposition du modèle de document SVG comme un élément central de la prise en charge de SVG. Ce serait bien mais pas indispensable pour les cas d'utilisation que j'ai en tête.

Oui, la prise en charge au niveau de la bibliothèque permettrait plus de fonctionnalités - mais si le moteur lui-même était capable de restituer (un sous-ensemble important de) données SVG, cela suffirait probablement pour permettre le rendu des actifs d'image vectorielle définis par ce sous-ensemble de SVG.

Ce problème est clairement plus important que cela, mais je serais heureux de prendre les actifs SVG existants et de les restituer correctement à différentes résolutions sans les convertir tous en images raster volumineuses.

Oui, l'importation de fichiers d'actifs SVG serait vraiment bien, mais la spécification pour SVG fait plus de 800 pages. Cela dit, importer simplement des fichiers statiques à rendre sur Skia (qui est une bibliothèque de graphiques vectoriels) ne devrait pas poser de problème. Alors je l'assume; comme toujours, je ne peux travailler qu'à temps partiel le week-end, donc vous ne verrez pas les choses tout de suite. De plus, j'ai une tonne de fichiers SVG, mais ils utilisent tous les mêmes éléments (collections d'icônes de flaticon), donc j'apprécierais des exemples de fichiers SVG de personnes qui souhaitent cette fonctionnalité.

Carlos.

J'ai aussi travaillé dessus un peu au fil du temps. Voici ce que j'ai trouvé :

Mise en œuvre au niveau du moteur

Cela semble intéressant pour les raisons suivantes :

1. En théorie, prend en charge quelque chose comme image: new AssetImage('graphics/background.svg') pour analyser du code C/C++ et traduire les données SVG en commandes de rendu Skia
2. Au moins un bon candidat qui devrait pouvoir se connecter à Skia assez facilement (https://github.com/svgpp/svgpp) au niveau du moteur
3. La logique SVG de WebKit serait géniale mais semble avoir beaucoup trop de dépendances
4. Je ne pense pas que librsvg porterait trop bien (étroitement couplé au Caire, transition vers Rust en tant que langue principale - il faudrait au moins trouver un moyen d'accéder à Skia en tant que backend)

Mais il a au moins quelques difficultés :

• Bien gérer le texte
• Gérer correctement le CSS (le cas échéant ? mais l'ajouter n'est pas une tâche simple)
• Étendre la prise en charge de fonctionnalités supplémentaires (ou permettre aux utilisateurs d'ajouter plus gracieusement la prise en charge de fonctionnalités) est un défi.
• On dirait qu'il est très difficile de gérer les animations

Mise en œuvre au niveau des fléchettes

1. dart:ui de Flutter offre un grand nombre des primitives de Skia dont SVG a déjà besoin
2. Je soupçonne que le rendu du texte serait beaucoup plus facile à gérer à ce niveau qu'au niveau du moteur
3. Il devrait être plus facile pour une plus grande partie de la communauté de maintenir/étendre
4. Devrait être capable de gérer à moindre coût l'interaction directe avec la logique d'analyse (peut-être pour gérer les exceptions et/ou les animations ?)

Mais rencontre quelques difficultés :

• Peut ne pas faire beaucoup mieux en prenant en charge CSS
• Peut ne pas faire beaucoup mieux soutenir les animations
• Serait probablement plus lent (mais peut-être pas assez pour avoir de l'importance, et pourrait potentiellement être compensé par le code SVG vers Dart compilé par AOT)

Données de test

En ce qui concerne les exemples de SVG, il serait probablement plus utile d'identifier quels SVG sont pris en charge à partir de la suite de tests 1.1 (ou, s'ils sont partiellement pris en charge, qu'est-ce qui est partiellement pris en charge à leur sujet). Ceux-ci peuvent être trouvés ici:
https://github.com/w3c/web-platform-tests/tree/master/svg/import

Ou ici avec quelques comparaisons PNG : https://www.w3.org/Graphics/SVG/Test/20110816/

@cbazza , de quelle manière envisagez-vous de mettre cela en œuvre ? À ce stade, je penche davantage vers une implémentation au niveau du package Dart.

De plus, je pense que la prise en charge du type d'icône est probablement facilement gérée avec quelque chose comme IconData. Il serait peut-être préférable de traiter cela séparément, car il ne devrait probablement prendre en charge qu'un seul chemin par point de code

Je pense à la "mise en œuvre au niveau de Dart" en plus de dart:ui.

2 cas d'utilisation de base :

(1) charger des fichiers svg d'icônes statiques avec quelque chose comme votre
"image : new AssetImage('graphics/background.svg')", où le
le fichier peut provenir du système de fichiers ou du réseau
dynamiquement.

(2) Prise en charge de svg basée sur un widget avec DSX (JSX comme construction)
qui ressemblerait beaucoup à :
https://github.com/react-native-community/react-native-svg

En ce qui concerne les "données de test", j'ai besoin de vrais fichiers de personnes qui ont besoin
ceci et non la suite de tests w3. Le support SVG dépendrait
sur ce que dart:ui prend en charge donc si un fichier svg recherché contient
des choses qui ne peuvent pas être faites avec dart:ui , je serais capable de
découvrez vite.

Carlos.

Je ne pense pas que nous devrions opter pour le modèle SVG natif réactif. Je veux prendre en charge des cas réels, mais je pense que couvrir la suite w3 nous donnerait une meilleure base de ce qui fonctionne et de ce qui ne fonctionne pas et à quel point ce serait difficile à mettre en œuvre)

Bon, il semble y avoir un malentendu...
Quand je fais (1), il faudra des fichiers SVG standard et j'essaierai de prendre en charge autant que possible étant donné dart:ui (Skia).
Lorsque je fais (2), qui consiste à créer des widgets pour gérer des constructions de type SVG, cela ressemblera beaucoup à cette bibliothèque react-native-svg. Ce sont 2 choses très différentes.

@cbazza le cas d'utilisation des svgs dans notre application concerne principalement les svgs unicolores que nous utilisons comme icônes. Voici un lien vers un fichier zip sur Dropbox avec une sélection de svgs récents qui sont représentatifs. https://www.dropbox.com/s/dp38wxc22625cvc/icons.zip?dl=0

Merci pour l'intérêt que vous portez ici, je serais heureux de voir un plugin SVG Flutter prendre vie !

J'ai écrit un outil qui effectue une analyse minimale d'une séquence de fichiers quelque peu SVG et vide les fichiers Dart que nous utiliserons plus tard pour afficher des animations d'icônes : vitool .

J'ai utilisé cet outil pour créer les données AnimatedIcons , vous pouvez vérifier le résultat en exécutant l' application de test manuel ( cd dev/manual_tests; flutter run -t lib/animated_icons.dart ).

Il est loin d'être optimal ou complet, mais fonctionne pour l'ensemble actuel d'icônes animées que nous avons, et quelqu'un devrait se sentir habilité à le bifurquer/étendre.

@deborah-ufw pour ces icônes de couleur unique, vous pouvez créer une police d'icônes et afficher les icônes à l'aide du widget Icône .

@amirh ne semble pas facile à créer des polices vectorielles de couleur

@amirh si vous lisez tout le fil ci-dessus, créer et définir une police avec des glyphes en tant qu'icônes est une série d'étapes supplémentaires qui doivent être suivies car SVG n'est pas pris en charge. Le support SVG est beaucoup plus efficace qu'une police. De plus, Zoechi a raison - tout art vectoriel qui a plusieurs couleurs est presque impossible à transformer en police.

Désolé - j'ai regardé les exemples d'icônes et j'ai pensé que vous n'aviez besoin que d'icônes d'une seule couleur.

@deborah-ufw, merci pour les fichiers, exactement ce que je cherchais et j'ai déjà trouvé des choses que mes fichiers n'ont pas.

@amirh , oui j'ai déjà vu votre excellent travail ;)

Avons-nous enfin un moyen direct de sourcer un fichier svg ou vecteur xml dans l'image pour le flutter

@Hixie : veuillez (re)considérer que pour les équipes mobiles natives multiplateformes, il s'agit d'un véritable problème, mais que seule une prise en charge partielle et relativement simple de SVG est nécessaire pour résoudre ce problème. Pour les responsables de la norme SVG, cela pourrait être considéré comme timide, mais Flutter est destiné aux développeurs mobiles, pas aux auteurs de normes générales. Flutter gagnerait le cœur des développeurs mobiles s'il soulageait leur douleur bien réelle, ne serait-ce que de manière pragmatique.

Veuillez également considérer que malgré ce besoin de longue date, l'approche de support communautaire n'a pas réussi à produire des solutions viables dans le concurrent Flutter Xamarin (au cours de mes 5 années d'expérience Xamarin - les bibliothèques ne peuvent pas gérer les exportations d'outils de conception, sont trop limitées, pas stables, source payante et/ou fermée).

Pour cette raison, je ne suis pas optimiste sur le fait que la communauté Flutter réussira là où la communauté Xamarin a échoué. J'estime que c'est pratique. la prise en charge partielle des icônes SVG est quelque chose que l'équipe Flutter pourrait fournir, en utilisant les primitives Skia existantes.

Cela correspondrait bien à l'objectif de Flutter : permettre aux développeurs mobiles de fournir une expérience utilisateur magnifique et haute performance en un temps record . Cela améliorerait la productivité, la fidélité et les performances (un SVG se charge beaucoup plus rapidement que tous ces PNG ; les icônes SVG ont généralement un coût de calcul modeste car une exigence de clarté visuelle conduit assez souvent à une forme de complexité modeste).

Le besoin principal est un flux de travail productif allant des outils de conception créative couramment utilisés (tels qu'Adobe) aux icônes d'application natives évolutives.

L'approche PNG actuelle est très coûteuse en termes de productivité et de taille d'application ; il est tellement primitif de générer et d'expédier chaque icône dans jusqu'à 9 bitmaps fixes (6 Android, 3 iOS) qui sont ensuite post-traités au moment de l'exécution. Le problème augmente régulièrement à mesure que les résolutions augmentent en taille et en variation.
Cela ressort comme un pouce endolori dans l'expérience de développement innovante et productive de Flutter, par ailleurs délicieuse. Je pense que Flutter a une réelle opportunité de gagner le cœur et l'esprit des développeurs ici,

De plus @dnfield, les fonctionnalités SVG mentionnées ci-dessus qui sont mentionnées comme des obstacles à la mise en œuvre dans Flutter ne sont pas pertinentes ou sont suffisamment rares pour que le recours aux PNG pour ces éléments de conception soit un inconvénient mineur.
Peu importe : CSS, HTML, SMIL, Document Model, scripting
Animation, Texte : assez rare pour se rabattre sur d'autres technologies pour cela

J'espère que la longueur de ce commentaire reflète la valeur d'une solution. Hth !

@VincentH-Net je suis à 100% avec toi car moi aussi je ressens la douleur !!! S'il vous plaît envoyez-moi certains de vos fichiers SVG. Xamarin a peut-être eu du mal à fournir un support SVG en raison du manque de moteur graphique vectoriel capable de le gérer ; ce n'est pas le cas pour Flutter avec Skia donc je suis très optimiste qu'une solution communautaire verra le jour.

FWIW, Xamarin a également Skia disponible dans SkiaSharp. SVG peut être délicat même pour une implémentation minimale.

Mais @cbazza, je serais très intéressé à collaborer avec vous sur ce

Et sur le front de l'animation, je pense que l'activation de Lottie satisferait de nombreux cas d'utilisation (et le ferait probablement avec de meilleurs outils pour les concepteurs).

@dnfield Je pense que ces animations Lottie peuvent facilement être reconstruites en tant que widgets Flutter

@dnfield , excellent, vous pourriez être le gars de bas niveau qui gère les changements au niveau du moteur pendant que je fais le travail de niveau supérieur sur le widget (analyse svg asynchrone, construction 'image' qui peut être mise en cache et envoyée au canevas lors des mises à jour de rendu, etc.).
oui, le travail de Lottie serait formidable pour le flux de travail des concepteurs/développeurs.
@zoechi pourquoi reconstruire quelque chose à la main avec des widgets alors que vous pouvez simplement importer un widget Lottie fonctionnel qui gère tout pour vous ? Cela dit, mon objectif précédent (2) ci-dessus fonctionnerait très bien avec les animations de widgets (d'où la raison pour laquelle je veux le faire aussi).

@zoechi - l'objectif serait de permettre aux concepteurs de créer de telles choses et de les rendre avec un minimum d'effort de la part du développeur. Un objectif secondaire serait de permettre leur chargement en tant que ressources au moment de l'exécution, plutôt que de nécessiter une précompilation.

Il en va de même pour SVG - oui, un développeur pourrait certainement convertir des données vectorielles SVG en Dart, mais idéalement, vous pouvez simplement inclure une ressource de dessin vectoriel (SVG ou non) et la rendre au moment de l'exécution.

En d'autres termes, je veux pouvoir dire à mon concepteur de créer un élément vectoriel une fois et pouvoir l'utiliser dans mon application Flutter avec un minimum de modifications (et sans que le concepteur l'exporte 5 fois dans divers formats raster qui finiront par invalide dès qu'Apple ou Samsung sortiront leur prochain téléphone).

divers formats raster

ouais, ça ressemble à la décennie précédente

https://github.com/luberda-molinet/FFImageLoading Cela vaut peut-être la peine d'être regardé, utilise Skia pour rendre SVG pour Xamarin

@escamoteur

Merci, ça a l'air vraiment bien, la seule chose qui manque, c'est qu'il n'est pas asynchrone ;)

Je n'utilise que des drawables vectoriels dans l'application Android récemment, et je ne vois aucune pénalité de performance notable. Les icônes sont nettes et la taille de l'application est beaucoup plus petite. Il est également beaucoup plus facile et rapide de tester différentes images. Cette solution @2 , @3 , @4 , @5 ,.... ressemble à un énorme pas en arrière dans un cadre aussi moderne que Flutter.
Je ne comprends pas pourquoi vous ne pouvez pas vous adresser à l'équipe responsable des drawables vectoriels Android et utiliser leurs idées ou leur mise en œuvre (si possible) pour résoudre ce problème.

J'ai joué avec des SVG dessinés sur une toile ici. Les éléments path sont probablement les plus difficiles à implémenter, mais il existe une API Skia qui aiderait vraiment si elle était exposée. J'ai expérimenté en l'exposant dans le moteur et j'ouvrirai un PR une fois que j'aurai eu un peu plus de temps pour l'affiner.

L'idée approximative serait quelque chose qui nous permet de créer un dart:ui Path partir d'une chaîne de données SVG, en utilisant l'API Skia déjà existante pour le faire. La méthode proposée est static Path Path.parseFromSvgData(String svgData) -> Path

Cela laisse encore du travail autour de l'analyse des différentes transformations/traits/remplissages qui peuvent être appliqués. Je pense que nous pouvons en emprunter une bonne partie au travail que @amirh a fait (je n'ai pas emprunté toute sa logique d'analyse de chemin car il semblait qu'il pourrait avoir des contraintes que SkParsePath n'a pas et comme SkParsePath devrait être plus efficace car il ne nécessitera que un aller-retour vers le côté natif pour tracer le chemin plutôt que des allers-retours pour chaque commande de dessin). Je n'ai pas non plus fini par utiliser @matanlurey pour des raisons similaires.

Voir https://github.com/flutter/flutter/blob/master/dev/tools/vitool/lib/vitool.dart , https://github.com/dnfield/flutter_svg (qui est actuellement capable de rendre les deux SVG inclus dans ce projet sur un canevas) et https://github.com/dnfield/engine/tree/path_svg (qui inclut actuellement également mon travail lié à PathMeasure/PathMetrics pour Lottie).

Salut @dnfield ,

Voici mon point de vue sur votre implémentation initiale. Permettez-moi simplement de dire que tout ce que je vais dire ne devrait faire aucune différence pour votre enthousiasme et vos progrès en matière de codage. Plus vous en faites, mieux c'est parce que nous pouvons toujours l'utiliser plus tard.

Le problème que j'ai est architectural et voici pourquoi. Pour que l'interface utilisateur soit réactive à 60 images/s, chaque image ne dispose que d'environ 16 ms pour s'exécuter avant de bloquer l'interface utilisateur. Supposons donc que la moitié est utilisée par Flutter pour faire son travail, cela laisse 8 ms pour notre analyseur SVG et il n'y a aucun moyen d'analyser un fichier SVG et de générer une image pendant cette période, quelle que soit la puissance de votre téléphone/tablette. La meilleure chose à faire est donc de cibler les appareils lents et d'avoir un code asynchrone capable de le faire en utilisant plusieurs images, mais la clé est que chaque image ne peut fonctionner que jusqu'à 8 ms, puis elle doit revenir et reprendre l'image suivante.

Vous ne pouvez donc pas analyser le XML à l'aide de dart: xml car il n'est pas asynchrone, il se bloquera jusqu'à ce que tout le fichier soit analysé. La génération de l'image doit également être asynchrone car vous ne pouvez pas tout faire en 8 ms. Il ne sert à rien d'optimiser prématurément le code, alors écrivez le meilleur code qui puisse être lu. J'ai un plan qui fonctionnera mais cela prendra du temps donc je veux que vous continuiez comme vous êtes parce que je peux toujours prendre votre travail et l'utiliser plus tard. Ma conception se branche sur la fonctionnalité de chargement d'image actuelle (AssetImage & NetworkImage) et l'utilisateur n'a qu'à spécifier un '.svg' au lieu de '.png'.

Carlos.

@cbazza juste une idée : l'analyse pourrait être effectuée dans un isolat. Je pense qu'il y a eu du travail pour pouvoir communiquer avec les canaux de messagerie d'isolats autres que l'isolat de l'interface utilisateur et pour transmettre des données entre les isolats par référence au lieu de les copier (pas sûr du statut ou de la progression cependant)

@cbazza - merci. Je ne pense pas que dart_xml soit la meilleure solution pour cela, mais cela fonctionne et permet de progresser dans la logique de dessin (et je ne voulais pas bloquer complètement cela tout en travaillant pour implémenter un analyseur XML asynchrone). J'ai également commencé à envisager d'implémenter ImageProvider , mais je pense que cela peut être un détail d'implémentation que nous pouvons masquer aux utilisateurs.

Je ne suis en aucun cas fixé sur aucune de ces API. Mais nous pouvons au moins commencer à dessiner des SVG, et probablement en prendre en charge des simples sur des téléphones décents.

Avez-vous l'intention de travailler sur l'API de lecture/analyse XML/SVG ?

@zoechi - nous pourrions encore obtenir une bien meilleure utilisation de la mémoire et probablement un meilleur temps d'analyse avec un modèle de lecteur en continu.

@zoechi oui j'ai regardé les isolats mais vous ne pouvez transmettre que des valeurs primitives (null, num, bool, double, String) et des listes et des cartes, et non des objets et/ou des arbres d'objets, donc la route asynchrone semblait meilleure. Une autre chose intéressante à propos de la détermination de l'analyse XML asynchrone est que les concepts s'appliqueraient à tout traitement d'arborescence asynchrone, comme par exemple le widget ou l'arborescence d'éléments. Cela permettrait la réconciliation asynchrone par exemple comme dans React's Fiber :)

@dnfield oui, je travaille sur un analyseur/processeur xml/svg asynchrone.

je me demandais simplement, le rendu SVG à l'aide d'une vue Web peut être une option?

Trop lourd pour des boutons simples et je ne suis pas sûr que la vue Web sera capable de gérer des changements de 60 images/sec. Je veux dire, disons que nous déplaçons l'icône ou la redimensionnons par exemple.

Je ne suis pas développeur iOS, donc je vois maintenant qu'iOS 11 prend également en charge les actifs vectoriels . Ce n'est pas du SVG, mais du PDF. Est-il plus facile de prendre en charge les ressources vectorielles PDF ?

Non. Quartz a de nombreux liens historiques avec PDF pour son système de rendu interne, ce qui facilite la tâche sur un appareil iOS. Skia n'est pas un moteur de rendu PDF, et le format de fichier (IMO) introduirait beaucoup d'ambiguïté sur ce qui est pris en charge et ce qui ne l'est pas (avec des outils pas aussi bons pour le réparer disponibles).

PDF est plus compliqué que SVG et le sous-ensemble PDF/X (qui est utilisé pour les éléments vectoriels) est conçu pour l'impression. J'aimerais bien voir la prise en charge du rendu PDF sur Flutter, mais pour nous, restons-en à SVG.

Je serais heureux avec un simple sous-ensemble VectorDrawable de svg (point, ligne, courbe, remplissage, déplacement). Flutter permet le RAD et vise à être véritablement multiplateforme (avec le bureau à venir), mais maintenant il ne le peut pas. Les plates-formes Android et Apple sont présentes sur les écrans 60"+ 4HD. Les graphiques vectoriels sont indispensables.

PS Excusez-moi, mais sans VG, votre travail (équipe flutter) va disparaître à la suite du travail de Kotlin en mode natif sur de nombreuses plates-formes, y compris iOS. Bien sûr, Kotlin natif est toujours en version bêta, mais Flutter l'est aussi. :(

@ohir Veuillez expliquer comment vous écririez une vue multiplateforme (code unique) qui fonctionne à la fois sur iOS et Android avec Kotlin natif. À moins que vous n'ayez l'intention de créer une version kotlin de l'abstraction du widget natif de réaction ?

Ne sous-estimons pas ce que feront les natifs de Kotlin car les possibilités sont infinies. Je suis arrivé à Flutter à partir de mes expériences créant quelque chose comme Flutter en utilisant Cocos2d-x. Ils pourraient aussi l'utiliser et/ou React Native et/ou Flutter car tout est open source et disponible pour la pollinisation croisée :)

Ouais tout à fait d'accord, l'amour et l'adoption de kotlin par les développeurs sont énormes et la compilation multiplateforme rend les possibilités infinies. Mais la comparaison entre la version bêta de Flutter et la version bêta native de Kotlin pour les plateformes mobiles multiplateformes est aujourd'hui inutile.
Quoi qu'il en soit, s'écartant du sujet.

@lukaspili Jusqu'à présent, il y a anko pour Android. Ses mises en page DSL pourraient également fonctionner intactes avec apko , linko et winko * inclus dans le sous-arbre de plate-forme respectif. Mais c'est OT pour le problème Flutter VG. [* n'existe pas encore].

Merci pour toute cette conversation passionnée ! Nous aimerions que ce problème reste centré sur les cas d'utilisation et les exigences des formats vectoriels et des API. Merci d'avance de rester dans le sujet ! :)

Que pensent les gens de diviser cela en un problème de prise en charge de SVG et de conserver celui-ci pour un format vectoriel de flottement TBD ?

Cela aurait du sens pour moi; le problème d'origine est formulé comme un format vectoriel spécifique à Flutter.

@cbazza Hourra pour le support de type svg. J'ai un tas de svgs sans icône que j'utilise pour dessiner l'ensemble de l'interface utilisateur d'une application. Comment dois-je vous les envoyer ?

J'adorerais essayer de passer au flottement, mais générer un million de pngs va sérieusement gonfler la taille de l'application et avoir l'air moche.

oui, veuillez m'envoyer une URL pour consulter les fichiers.

Donc, à ce stade, sur ce front, je poursuis une approche basée sur Flatbuffer. Je travaille sur la définition d'un schéma Flatbuffer qui pourrait capturer les commandes de dessin vectoriel - plus ou moins la façon dont Skia capture les chemins.

Je pourrais voir que cela est semi-interopérable avec SVG (par exemple, avoir un outil de conversion SVG -> Flatbuffer, ou Android Vector Drawable XML -> Flatbuffer, qui pourrait couvrir de nombreux cas d'utilisation de SVG), et éviter de nombreux problèmes de performances que nous 'd visage avec SVG (manque d'analyse XML en continu, besoin d'analyser les données de chemin SVG, puis de les envoyer au natif bit par bit). J'ai également pu produire des fichiers binaires plus petits que le format SVG (bien qu'il reste à voir dans quelle mesure cela évoluera).

Il devrait également être possible de clarifier dès le départ dans l'outil de conversion les fonctionnalités qui ne sont pas prises en charge dans un SVG donné (par exemple, "les éléments étrangers ne sont pas pris en charge par ce format").

Le bit d'analyse Flatbuffer pourrait être fait dans Dart ou C++ - la seule chose dans Dart est qu'il serait toujours agréable d'avoir un moyen de regrouper les commandes vers Skia pour créer des chemins et dessiner sur Canvas.

il existe une solution potentiellement beaucoup plus simple qui consiste à effectuer une analyse au moment de la compilation et un résumé des opérations de nœud SVG vers Skia ... cela éliminerait complètement l'analyse d'exécution de SVG et permettrait la mise en cache en mode conservé des tampons intermédiaires

@sandrobilbeisi tu veux dire comme https://github.com/amirh/flutter/commit/69de4bbf3177d9766a386c55b27a12619da43a05 ?

c'est remarquable ... et il y a aussi vitool https://github.com/flutter/flutter/blob/master/dev/tools/vitool/lib/vitool.dart

mais je pensais plus comme une étape de construction comme celle que Xcode utilise avec les actifs SVG pour les livrables iOS

@sandrobilbeisi voulez-vous dire créer un bitmap à partir de svgs pendant la compilation?

BTW le package Xamarin ffimageloading met en cache les bitmaps rendus donc un seul rendu. Il met également en cache les images réseau et les images redimensionnées, ce qui le rend très rapide

pas bitmap , mais Skia qui est à l'origine un moteur graphique vectoriel pour < canvas >
https://skia.org/ ( ps acquis par Google il y a une dizaine d'années : http://www.satine.org/archives/2007/03/05/the-skia-source-code-dilemma/ )

Vous voulez dire convertir svg en format d'image skia ?

Oui

Lien @cbazza vers les fichiers de test SVG : https://github.com/slingshotapp/artwork

Existe-t-il un moyen d'exécuter vitool au niveau du projet? Je peux créer le fichier généré mais il a besoin d'accéder à de nombreuses classes privées qui m'empêchent d'ajouter le .g.dart à mon projet.

Se référant à l'outil à <flutter>/dev/tools/vitool : #dart bin/main.dart --asset-name=_$hello --output=here.g.dart ./test_assets/horizontal_bar_relative.svg

@emilieroberts Merci mais ces fichiers ne sont pas au format SVG mais plutôt au format vectoriel Android personnalisé qui est très similaire à SVG.

@cbazza oups, en effet - la plupart des svgs sont là-haut maintenant :)

@cbazza pouvez-vous clarifier ce que vous entendez par vecteur Android personnalisé ? Ils ont une balise <svg , contrairement aux drawables vectoriels Android.

Quoi que ce soit fait avec Vitool en ce moment, c'est incroyable, mais je n'ai trouvé aucune trace de documentation nulle part. Je peux lui écrire un exemple avec AnimatedIcons.arrow_menu , mais j'aimerais aussi savoir ce qu'il faudrait pour faire cela à partir d'actifs provenant de l'extérieur du SDK Flutter.

@fmatosqg vous avez raison, le code utilisé pour exécuter les animations générées par vitool est privé au framework. La raison en est qu'il y a encore des questions ouvertes sur ce qui serait un bon format vectoriel pour Flutter (comme suivi dans ce numéro), et je voulais éviter une API publique qui prend en charge n'importe quel format spécifique (car cela s'engagera dans ce format si nous ne voulons pas de changements de rupture à l'avenir).
La surface actuelle de l'API pour AnimatedIcon nous permet d'utiliser des fichiers générés par vitool en interne dans le framework, tout en pouvant remplacer l'implémentation sous-jacente et le format vectoriel sans casser aucun client.

Si vous souhaitez générer des fichiers avec vitool et l'utiliser dans votre projet, vous pouvez le faire en copiant le code de packages/flutter/lib/src/material/animated_icons et en l'incluant dans votre projet (cela garantit également que votre projet ne se cassera pas si nous changeons les machines utilisées par AnimatedIcon).

Désolé pour la gêne occasionnée et espérons que nous aurons bientôt une meilleure solution.

J'aime cette idée, surtout si https://github.com/flutter/flutter/issues/13834 va de l'avant. Je pense qu'une telle chose ne devrait pas faire partie d'un SDK monolithique, mais pas particulièrement concernée s'il s'agit d'un package officiel ou communautaire.

Il existe un format compact pour le sous-ensemble de svg inventé pour Shiny (cadre de bureau Go) par quelqu'un du grand G . Sa représentation binaire et peut amener la taille par défaut de l'icône du lanceur Android à moins de 100 octets. Comme indiqué ci-dessus dans le fil - et IMSO - les vecteurs de dessin devraient être le devoir de Skia, avec Flutter passant une représentation la plus compacte disponible. C'est le devoir de l'outillage de compiler les fichiers svg res/ au format interne.
[ @amirh Re : questions ouvertes sur ce qui serait un bon format vectoriel ]

Donc FWIW, dans flutter_svg j'ai formulé le code de telle sorte que tout le dessin soit vraiment fait par des objets intermédiaires. Le travail lié à SVG consiste essentiellement à mapper SVG à ces objets. Il reste encore du travail à faire pour stabiliser complètement ce format intermédiaire (par exemple, j'ai commencé sur le support du texte mais il est très mauvais en ce moment).

J'ai commencé à porter la prise en charge d'Android Vector Drawables dans le framework (moins la prise en charge des références externes de couleur et de style, etc., et ne prenant pas encore en charge les chemins de clip ou probablement d'autres fonctionnalités). Il devrait être tout à fait possible de prendre en charge Shiny de cette manière également, ou vraiment tout autre format. J'aime travailler avec SVG pour cela à ce stade car cela aide à couvrir de nombreux cas intéressants à prendre en charge, c'est donc mon objectif principal pour l'instant.

Après avoir lu ce fil - et un long sur le support JSX - je ne peux m'empêcher de penser qu'il existe un problème de gouvernance. L'équipe Flutter risque d'être tirée dans mille directions différentes alors que les développeurs réclament ce qu'ils pensent être important. Peut-être que Flutter devrait instituer des projets "d'incubateur", comme Apache. Les fonctionnalités demandées sont implémentées par des plugins, de manière open-source, éventuellement avec des contributions de l'équipe Flutter elle-même. Si les plugins obtiennent un support, une efficacité et une popularité suffisants, ils deviennent des candidats pour être inclus dans le framework Flutter de base.

Je pense que cela permettrait aux développeurs les plus virulents de mettre leur "code là où il y a la bouche" plutôt que de recourir aux battements de poitrine et de sourcils exposés ici, et laisserait l'équipe Flutter plus libre de se concentrer sur l'ingénierie de base.

Je suis respectueusement en désaccord. Si vous examinez les jalons comme bucket5, vous saurez sur quoi l'équipe travaille et si vous allez à bucket6, vous saurez ce qu'ils considèrent comme une priorité. Vous pouvez également savoir ce qu'ils ne considèrent pas urgent si vous regardez d'autres jalons sur la route.

De plus, la raison d'ajouter quelque chose au noyau de flutter devrait être plus que "Je peux faire un plugin et cela fonctionne pour tout le monde et tout le monde le veut". C'est une raison pour créer un plugin, mais pas assez pour être ajouté à ce dépôt ou à d'autres dépôts flutter.

Un exemple de choses qui ne devraient pas être des plugins : des choses que @dnfield a ajoutées au moteur afin qu'il puisse bénéficier et utiliser le plugin qu'il possède. Un tel plugin n'aurait aucune chance de faire toutes les fonctionnalités qu'il fait s'ils n'étaient pas ajoutés au moteur.

Être vocal est important, mais ne garantira jamais que cela passera. Mettre le code là où se trouve la bouche est également important mais pas encore suffisant. Ce projet a beaucoup de transparence et ils écoutent clairement ce que disent les développeurs, mais ce n'est pas une démocratie et cela ne signifie pas que le vote populaire gagnera sans raisonner sur les conséquences.

Oui, ne craignez pas que les développeurs travaillant sur le framework Flutter soient distraits par des discussions sur les bogues. :-) Nous lisons les discussions et nous nous soucions beaucoup des opinions de chacun, mais en fin de compte, nous avons des principes directeurs clairs et nous n'allons pas simplement réagir aux voix les plus fortes. Nous effectuons une analyse minutieuse du marché pour déterminer ce qui intéresse la communauté dans son ensemble.

Conversation intéressante qui me laisse avec une simple question. Comment l'équipe Flutter recommande-t-elle de passer de la phase de conception (SVG) aux graphiques vectoriels dans Flutter ?

@lukepighetti , vous pouvez essayer https://github.com/dnfield/flutter_svg et vérifier jusqu'où cela vous mène.

Personnellement, je ne suis pas satisfait de la solution proposée pour les fichiers SVG dans Flutter. J'ai utilisé le package flutter_svg et je n'en suis pas satisfait.

Le support SVG doit être supporté nativement à mon avis dans la bibliothèque standard. Si nous allons commencer à utiliser Flutter sur des écrans plus grands comme les applications de bureau et les sites Web, c'est un must.

@socialmammoth pouvez-vous préciser les lacunes que vous constatez ?

Une chose sur laquelle je réfléchis depuis un moment est de savoir s'il serait utile de prendre en charge le format .skp (SKIAPICT). Je pense qu'il y a de bonnes raisons de ne pas le faire directement - le format n'est pas garanti pour être stable d'une version à l'autre de Skia étant la plus importante.

Cependant, il a des propriétés intéressantes - en particulier, il est possible d'obtenir Chrome/Chromium pour générer un SKP (peut-être d'un SVG rendu), et il est très probable que nous prenions déjà en charge la plupart ou la totalité des commandes de dessin Skia nécessaires pour réellement rendre la grande majorité des SKP.

J'ai prévu de créer une solution de type code-gen pour le plugin SVG, afin que vous puissiez générer du code Dart/Flutter à partir d'un SVG. Je pense qu'à ce stade, il serait probablement plus intéressant d'étudier un processus de construction SKP vers Dart - une partie du code écrit pour Flutter SVG pourrait être portée sur le framework (par exemple, le RawPicture et l'infrastructure associée, qui correspond à peu près à un RawImage ), et nous pourrions câbler quelque chose qui prendrait la sortie d'un SKP (peut-être généré à partir d'un SVG tel que rendu par Chrome, qui est à peu près la référence pour le rendu SVG de toute façon). Il devrait être possible de créer des outils qui prendraient un SVG, invoqueraient Chromium sans tête pour le rendre à un SKP, puis transformeraient le SKP en un ou plusieurs fichiers Dart que Flutter pourrait rendre au moment de l'exécution.

Un grand domaine que cela ne résout pas est le chargement dynamique d'un graphique vectoriel au moment de l'exécution (par exemple SvgPicture.network ), mais je suis intéressé par des commentaires sur la question de savoir si cela serait toujours une solution valable/acceptable même avec cette limitation.

Je dis aussi cela avec la conviction qu'à ce stade, nous n'obtiendrons jamais de support "natif" pour SVG dans Flutter. C'est en partie parce que SVG lui-même a beaucoup de bagages (XML, CSS, capacité à récupérer des actifs externes) qui ne sont pas triviaux à implémenter en dehors d'un navigateur/logiciel de rendu HTML et ajouteraient beaucoup de gonflement au logiciel que nous essayons se pencher. C'est aussi en partie parce qu'il est tout à fait possible d'implémenter pas mal de SVG sans apporter d'énormes changements au framework - bien que certaines choses ( filterEffect s et textPath s en particulier en ce moment) seront probablement bénéficier de quelques ajustements supplémentaires au moteur.

Je pense que pouvoir charger des SVG directement depuis le réseau est un avantage majeur, même si cela signifie que nous ne prenons en charge qu'un sous-ensemble des fonctionnalités du format.

Avoir un format vectoriel spécifique à Flutter ressemble à ce que fait Android avec VectorDrawables, ce qui, même s'il fonctionne bien, signifie également qu'il ne peut pas bénéficier de la plupart des outils qui existent déjà pour SVG. Cela rend également difficile l'itération des conceptions en raison de toutes les conversions de format.

J'aimerais voir Flutter prendre en charge les SVG de manière native, car c'est ce que les développeurs front-end attendent de leurs frameworks en 2018. J'aimerais que les développeurs front-end trouvent Flutter accessible, car je veux que l'écosystème se développe.

@dnfield

.skp (SKIAPICT).

Approche intéressante à mon humble avis. Mais alors, les outils Flutter (au moins dans AS) doivent gérer la conversion de manière transparente. Les concepteurs sont quelque peu habitués aux restrictions imposées par les importations vectorielles d'Android actuelles, ils seront donc sûrement en mesure de gérer d'autres ensembles de choses à faire et à ne pas faire.

Pour le développeur occasionnel, le manuel devrait indiquer : " Déposez vos dessins svg ici, annotez ici, utilisez à volonté. Si votre svg ne respecte pas le sous-ensemble SVG pris en charge (voir ici), le compilateur ou l'analyseur ( flutter analyze ) le dira vous ce qui ne va pas dans votre svg ". Ou quelque chose comme ça.

@dnfield

obtenir Chrome/Chromium pour générer

Bon pour le PoC et les tests, mais la vraie solution à mon humble avis peut ne pas nécessiter une dépendance aussi énorme - et une dépendance difficile à scénariser en tant qu'étape intermédiaire CI. Bien sûr, lors de la version bêta, puis en tant que deuxième "voie difficile", cela pourrait convenir - par exemple. pour obtenir un dessin animé facile que skPicture permet. Je peux me tromper ofc. car les concepteurs ont généralement un grand seau avec des navigateurs sous le rabat de leur ordinateur portable. Néanmoins, gardez à l'esprit que les œuvres d'art mutent souvent. Non seulement au stade du prototypage, mais aussi à l'approche du moment du lancement et les développeurs sont dans la fièvre de la chasse aux bogues.

[C'est à dire. Soit nous avons besoin d'un outil de flutter traitant de l'importation svg conforme, soit nous avons besoin d'un moyen où le chrome est entièrement entre les mains du concepteur. Pas du développeur.]

PS. La méthode du package launcher_icons pourrait faire au démarrage : flutter packages pub run flutter_svg_to_skp:main -i path/to/svgs -o path/to/skps .

-- mon ¢2

@cachapa

pouvoir charger des SVG directement depuis le réseau

Il s'agit d'un travail pour un énorme package séparé qui traitera de la validation et des solutions de contournement
autour des incompatibilités possibles et des caprices du producteur.
Obtenez d'abord le moteur pour dessiner le format vectoriel fourni par le développeur que le package "Charger SVG à partir du réseau" utilisera sûrement. :)

Juste pour être clair @cachapa et @ohir - flutter_svg _déjà_ prend en charge le chargement d'un SVG sur le réseau ( SvgPicture.network ). Cependant, ce paquet ne finira jamais par prendre en charge l'intégralité de la spécification SVG - le but est vraiment de ne prendre en charge qu'une partie suffisante de la spécification pour rendre la plupart des SVG. Il le fait déjà, avec les principales exceptions à ce stade étant fliterEffect s (donc pas de flous, de filtres de couleur, etc.) et beaucoup de support lié au texte - mais il y en a d'autres ( marker s ne sont pas pris en charge, certains types de références xlink:href ne sont toujours pas pris en charge). Il y a aussi certains problèmes que je ne prends pas en charge intentionnellement, comme la spécification CSS complète, les scripts et l'interactivité.

@lukepighetti Je pense que cette attente n'existe vraiment qu'avec les développeurs front-end basés sur le Web. Qt prend en charge SVG, mais seulement un sous-ensemble limité. GNOME prend en charge un peu plus avec librsvg, mais encore une fois, cela pose quelques problèmes (et il est vraiment difficile à utiliser en dehors des environnements Linux). Je suis ravi de voir ce qui se passe avec resvg, mais je ne connais aucune bibliothèque graphique qui l'intègre.

@dnfield Je ne veux pas critiquer votre travail car vous avez fait un excellent travail et je vous en remercie énormément. Je suis juste déçu que la couleur ne fonctionne pas comme prévu. J'ai dû choisir ma propre couleur, je ne suis pas une artiste, je suis aussi daltonienne.

Flutter doit prendre en charge les SVG de la même manière que les navigateurs modernes. C'est un impératif. Nous devons pouvoir utiliser des actifs copiés ou importés directement d'une page Web sans modification.

Franchement, Dieu merci, au moins il y a un package, mais nous avons besoin de couleur, nous avons besoin d'effets, si les performances sont un problème, rendez-les facultatifs pour que les gens désactivent les fonctionnalités et non les forcent à activer les fonctionnalités.

Nous avons besoin d'une prise en charge complète des spécifications pour les SVG. Je suis d'accord avec @lukepighetti . Avec Hummingbird, c'est un must, sinon les développeurs Web se moqueront de Flutter et lui donneront une passe difficile.

Même @yjbanov le mentionne dans son article ici : https://medium.com/flutter-io/hummingbird-building-flutter-for-the-web-e687c2a023a8

Puisque @dnfield a mentionné 'resvg', @SocialMammoth peut-être que flutter_svg devrait également viser le support 'SVG statique' au lieu du support svg complet :
http://www.w3.org/TR/SVG11/feature#SVG-statique ,
qui je pense devrait faire plaisir à tout le monde.

Même Chrome ne prend pas en charge toutes les fonctionnalités SVG et, en particulier, le rendu du texte de droite à gauche est bogué (sans aucun progrès ces dernières années). En d'autres termes, je ne pense pas que la prise en charge complète de SVG soit réaliste. SVG-static semble être un sous-ensemble raisonnable. Dans flutter_svg, il me manque du text hadling (y compris du texte sur le chemin), des filtres et des masques. Ce serait bien d'avoir un support dans Flutter pour construire quelque chose comme ça https://drifted.in/horologium-app/

@SocialMammoth

Flutter doit prendre en charge les SVG de la même manière que les navigateurs modernes

Non. Les applications Flutter doivent être légères. Ce problème ne concerne pas un package tout-puissant pour gérer tout SVG, il indique explicitement "supporter un format vectoriel dessinable" (ne supporte pas SVG ). L'objectif, si je comprends bien, est jusqu'à présent de débarrasser autant que possible toutes les applications flottantes des actifs bitmap. Et cela au niveau du moteur. @dnfield a fait un excellent travail via un package. Il est maintenant temps d'obtenir des graphiques vectoriels disponibles auprès de Dart sans gonfler le moteur de flutter (skia) ou l'application elle-même . L'utilisation .skp semble être un bon choix pour cet objectif. Il permet déjà plus que le dessin vectoriel d'Android et il est déjà dans le moteur. Les concepteurs s'adapteront à son ensemble de fonctionnalités.

@ohir Je suppose que nous ne sommes pas d'accord alors. Un framework frontal qui ne prend pas en charge les fichiers SVG est vraiment une mauvaise blague.

Eh bien, je ne pense pas que le flutter BESOIN de svg soit utile, mais ce serait bien. Et si ce n'est pas svg, alors un format facile à obtenir à partir de votre application graphique vectorielle typique.

Fondamentalement, SVG est le format vectoriel standard à utiliser ici, mais nous ne pouvons pas nous attendre à ce que toutes les fonctionnalités de SVG soient prises en charge. L'objectif a toujours été de prendre en charge le minimum afin d'importer des actifs vectoriels à partir d'applications graphiques vectorielles typiques. Quelles applications graphiques vectorielles peuvent lire et écrire .skp ?

Mon test pour savoir si un format vectoriel est suffisamment omniprésent est s'il est disponible dans Adobe Illustrator, Affinity Designer et Inkscape. Autant que je sache, cela laisse à peu près SVG. Et je suis d'accord que nous n'avons pas besoin de toutes les fonctionnalités SVG. Seuls les traits et les remplissages de chemins de base conviennent.

Je ne peux pas dire cela avec autorité, mais je soupçonne qu'il serait plus facile d'implémenter un sous-ensemble de SVG que de convaincre les applications graphiques vectorielles de prendre en charge .skp ?

@lukepighetti : L'idée de Dan est d'utiliser le format interne du moteur. L'essentiel de cette solution est de convertir SVG au format que le moteur comprend. Peu importe qu'Inkscape connaisse ce format tant qu'un convertisseur viable existe.

J'étais dans le doute hier, mais aujourd'hui, après un peu de recherche, il me semble que l'automatisation du chrome est bien supportée. Si le chrome sans tête peut être utilisé avec un proxy de rendu , il peut également devenir un convertisseur svg->skp . Un peu lourd, mais abordable. Des fruits à portée de main en effet, @dnfield :).

Tout cela correspond bien aux objectifs fixés par @Hixie il y a près de trois ans.

@dnfield s'il vous plaît corrigez-moi si je me trompe.
Je suppose que .skp est essentiellement le format binaire d'une image Skia.

Étant donné que dart:ui dispose également d'un wrapper pour Skia Picture qui peut être généré à partir de Dart land, le contenu de ces images ne contiendra-t-il pas différentes capacités Skia ? Fondamentalement, celui de Chrome utilisera toutes les fonctionnalités de Skia, tandis que celui de dart:ui ne le fera pas (limité par ce qui a été rendu disponible via le moteur Flutter) ? Un peu bizarre pour l'argument "performance", n'est-ce pas ? Flutter engine & dart:ui supprime tout Skia qui a été jugé lent (sans afficher les chiffres de performance), mais vous pouvez ensuite utiliser tout cela s'il arrive via le fichier .skp généré par Chrome ?

Autre chose, lors de l'utilisation .skp , comment spécifieriez-vous les couleurs d'une icône, si par exemple l'icône utilise 2 couleurs ou plus ?

Que diriez-vous du vieil argument selon lequel en utilisant Dart dans Flutter, vous contrôlez chaque pixel ? Pour moi, le package flutter_svg prenant en charge "svg static" est la voie à suivre car il permettra l'innovation future dans Dart Land. En contournant Dart et en laissant simplement C++ le gérer, il semble que Dart ne puisse pas le pirater.

Skia semble supporter SVG. Pourquoi Flutter ne fournit-il pas directement le support SVG ?

D'après ce que je peux dire, l'équipe Flutter veut garder la taille du package Skia aussi petite que possible. Je ne savais pas que Skia supportait SVG, mais si c'est le cas, c'est un fruit à portée de main. Notez qu'il existe un autre problème lors de l'ajout de la prise en charge de Lottie pour Flutter, car Skia la prend en charge.

Skia ne prend pas en charge l'importation de dessins à partir de SVG, mais dispose d'un support expérimental pour la création de SVG (ce qui n'est pas aussi utile ici).

Et oui, la taille de l'emballage est une préoccupation.

S'il vous plaît, si vous souhaitez demander le support SVG, consultez : https://github.com/flutter/flutter/issues/15501

Ce bogue concerne spécifiquement la prise en charge des graphiques vectoriels sans prise en charge de SVG.

Pour les personnes intéressées par un format graphique vectoriel, je suis curieux de connaître vos cas d'utilisation.

Je suis au courant de ceux-ci jusqu'à présent:

• Icônes. Les images statiques qui peuvent avoir besoin d'être recolorées dynamiquement (par exemple, grisées lorsqu'elles sont désactivées) et peuvent avoir besoin d'avoir différents niveaux de détail en fonction de la taille de rendu cible. Peu de chances d'avoir du texte.

• Icônes animées : deux icônes comme décrit ci-dessus, et une description de la façon de passer de l'une à l'autre en toute transparence.

• Arrière-plans : images qui peuvent être beaucoup plus grandes que l'écran, peuvent être affichées avec une parallaxe ; des scènes généralement simples avec des formes, des dégradés et des ombres, peu susceptibles d'avoir du texte.

Existe-t-il d'autres cas d'utilisation qui motivent votre besoin de graphiques vectoriels ? Veuillez les décrire ici. Merci.

Prise en charge de plusieurs résolutions avec un seul graphique, en particulier avec une compatibilité ascendante pour les écrans à plus haute résolution

Mon application est essentiellement un compagnon d'une conférence. Je souhaite inclure des cartes de l'hôtel, avec la possibilité de faire un panoramique et de zoomer. L'utilisation d'un raster haute résolution n'est pas pratique pour des raisons de taille et de performances ; les graphiques vectoriels sont parfaits.

En ce moment, j'utilise une vue Web PDF intégrée, ce qui est super gênant et ne fonctionne qu'en ligne (bien que je pourrais probablement contourner cela si je le devais).

• Les boutons personnalisés "ressemblant à de vrais" sont pratiquement inaccessibles sans graphiques vectoriels. Surtout ceux qui tournent, inclinent ou fondent le cisaillement.

Pour ajouter à ce que Dan a dit : seulement 1 Ko de source vectorielle peut produire des détails fins et une image fluide à la fois sur une tablette 7" et sur un téléviseur 105" 4HD. Cas récent de l'application Kiosk de caisse enregistreuse pour écrans 10 ou 14" (face caissier) et 5 ou 7" (face client). L'ensemble de plus de 5000 dessins vectoriels de goodies avait une taille inférieure à 5 Mo. Seul le sous-ensemble de "légumes" (~ 150) converti en pngs pour les deux écrans exacts utilisés dépassait 30 Mo. L'ensemble d'inventaire complet peut se terminer dans la plage de Go.

PS La prochaine grande chose serait d'avoir des graphiques vectoriels avec des régions tactiles définies, par exemple, via un remplissage choisi. Cela aurait épargné des milliers de lignes de code pour toute la classe d'interfaces principalement statiques mais riches en détails.
Comme dans les manuels d'utilisation de machines interactifs.

Rêves de côté - laissez simplement nos concepteurs utiliser d'abord des dessins vectoriels simples :)

Merci pour les commentaires jusqu'à présent. Très utile.

@ohir Pouvez-vous élaborer sur "tourner, incliner ou fondre" ?

Ma solution de contournement pour cela dont je suis en fait très satisfait consiste à utiliser le package path_parsing (https://pub.dev/packages/path_parsing) pour générer des commandes de dessin de canevas à partir d'une chaîne de chemin SVG, puis en utilisant ceux-ci pour créer un widget CustomPainter qui le dessine. Pour les autres formes SVG en plus des chemins (rect, cercle, etc.), je les traduis simplement manuellement en commandes de dessin, ce qui est un peu fastidieux mais pas trop difficile.

Cela fonctionne très bien pour les icônes vectorielles simples et vous permet d'utiliser le même widget avec différentes tailles et couleurs dans toute l'application.

Voici le code : https://gist.github.com/jpotterm/7b30739e0af722baf97a397d9841d908

Cela pourrait être très utile s'il existait un outil de ligne de commande flutter officiel qui analysait un fichier SVG et produisait des commandes de dessin de canevas qui produiraient un résultat similaire.

@Hixie
Par exemple. https://dribbble.com/shots/1083175-Air-conditioning-controller#
Le bouton rotatif central et la jauge qui l'entoure peuvent être méticuleusement dessinés avec l'API Canvas actuelle, mais il peut également tenir dans 2Ko (xml svg) puis environ 300-500B de drawable. Si des graphiques vectoriels et des transformations affines rudimentaires du niveau Skia étaient exposés via une interface de «graphiques vectoriels», ce bouton pourrait être rendu vivant simplement en appliquant des remplissages aux segments de jauge et en faisant tourner un chemin du petit cercle indicateur.

Le plus important est que tout ce bouton, avec des couleurs et d'autres détails, soit dessiné exactement comme prévu par le concepteur - car ce serait tout son travail juste intégré. L'interface des dessins vectoriels + remplissage + dégradés + bon concepteur peut ressembler à : https://www.artua.com/app-design-deckadance/
Des transformations raffinées de la part du développeur rendront une telle conception réactive et dynamique.
En ce qui concerne les transformations de biais et de cisaillement : peut par exemple. être utilisé pour modéliser un changement de levier de commande.
("Melt" mot-changement probablement induit par le fantôme de Salvadore Dali ;)

/hors sujet/

@jpotterm
Cela pourrait être très utile s'il existait un outil de ligne de commande flutter officiel qui analysait un fichier SVG et produisait des commandes de dessin de canevas qui produiraient un résultat similaire.

J'ai produit quelque chose de similaire. Générateur de code qui recherche une Annotation et prend le PathData SVG spécifié et génère un getter qui renvoie un objet Path. Si les gens veulent, je pourrais le nettoyer et l'ouvrir.

L'application à laquelle je contribue est parfaitement adaptée aux graphiques vectoriels. Il contient des centaines de petits graphiques au trait noir et blanc qui constituent l'interface utilisateur. Ceux-ci peuvent être teintés et redimensionnés.

Faire cela en plusieurs couleurs à toutes les densités différentes serait horrible à faire, non durable et rendrait le paquet final géant. Ces images proviennent de graphiques dessinés à la main.

Merci à tous pour vos commentaires. Commentaires très utiles.

Pour les personnes intéressées par un format graphique vectoriel, je suis curieux de connaître vos cas d'utilisation.

Un autre cas d'utilisation est essentiellement tout ce qui nécessite des graphiques dynamiques :

• graphiques
• barres de chargement
• dessin
• etc

Je suis en fait très surpris que Flutter ne supporte pas cela puisque Skia prend en charge un sous-ensemble de SVG (les parties utiles de toute façon).

Je voudrais utiliser des SVG pour l'art. Une tablette plein écran de qualité PNG peut être de 2 Mo ou plus, alors que son équivalent SVG peut être de 5 à 10 Ko. Ajoutez quelques écrans, et nous parlons de 20 Mo au forfait au lieu de 100 Ko.

Pour les graphiques programmatiques, je suis un grand fan de CustomPaint, donc je n'utiliserais jamais SVG pour des choses comme les graphiques, les barres de chargement, le dessin, etc. Pour ceux qui sont préoccupés par l'API CustomPaint, c'est mentalement un peu comme l'API HTML Canvas. Et oui, bien que je convienne qu'il est coûteux d'écrire des choses dans CustomPaint, ce que vous obtenez à la fin est solide comme le roc et rend très rapidement et très joliment.

Si vous souhaitez prendre en charge SVG, vous devez prendre en charge toutes les fonctionnalités SVG, telles que les dégradés, les traits, etc. Cela n'a pas été fait dans le projet Android et cela déclenche des avertissements pour les développeurs, puisque presque tous les autres développeurs. les plates-formes prennent en charge SVG et les vecteurs. C'est la base du graphisme, faites-le bien !

@harounhajem , veuillez consulter https://github.com/flutter/flutter/issues/15501 pour ce sujet, ainsi que https://github.com/dnfield/flutter_svg

@PierBover pour les graphiques en particulier, veuillez considérer https://pub.dev/packages/charts_flutter

Je viens de sauter dans Flutter. J'étais en train de refactoriser une application personnelle de Ionic 3 à Ionic 4 et c'était (encore) totalement différent et cela nécessitait une application à partir de zéro.
J'ai donc décidé de passer à Flutter et de l'essayer. Comme je l'ai dit, cette application était terminée et fonctionnait, ce qui inclut de nombreux graphiques et icônes que j'avais prêts sur mon application. Je ne suis pas un designer et je dois payer pour ces conceptions.
Je comprends que je ne suis pas le seul dans cette situation, à vouloir réutiliser ses assets SVG.

@erperejildo - voir https://pub.dev/packages/flutter_svg

(je ne sais pas pourquoi ce n'est pas fermé alors)

Parce que le problème réel - prendre en charge un format vectoriel dessinable autre que SVG - n'est pas résolu ?

oh, ma faute @jonahgreenthal. Je suis venu ici à la recherche d'un support SVG et j'ai vu que le troisième commentaire demandait la même chose

Uber l'a fait pour iOS : https://github.com/uber/cyborg
Il serait intéressant de voir quelque chose comme ça dans Flutter.

Des mises à jour à ce sujet ?

@dnfield qui a bien fonctionné en affichant un svg en tant que nouveau widget mais cela ne fonctionne pas avec la propriété AssetImage . J'ai besoin de l'afficher à l'aide d'un widget CircleAvatar

@Hixie il existe également un cas d'utilisation où l'icône svg doit avoir plusieurs couleurs car cela aide l'utilisateur à comprendre la signification de l'icône. J'espère donc que la solution inclura également la possibilité de personnaliser la couleur du thème.

Actuellement, certaines personnes suggèrent de convertir SVG en police et de l'utiliser de la même manière que le package d'icônes, mais nous ne pouvons pas avoir plusieurs couleurs dans l'icône dans ce cas.

4 ans de commentaires divers sans aucune solution utile. En bref - non, pas, possible. Non, pas prévu.

Pouvons-nous au moins savoir pourquoi est-ce si problématique/difficile ?

Flutter_svg a un support décent pour SVG dans Flutter. Rive prend également en charge un format vectoriel pour le flutter.

Ce problème concerne la création d'un nouveau format vectoriel. ça prend du temps :)

@dnfield , il existe des widgets avec des propriétés d'arrière-plan que nous ne pouvons pas transmettre aux svgs. Existe-t-il un moyen d'archiver cela?

veuillez ajouter un support svg approprié au lieu de créer un nouveau format. Svg est la norme de facto.

Chaque fois que je crée une application, il y a généralement un site Web associé, et les sites Web utilisent svg, et ils utilisent des svg magnifiquement animés, qui sont légers et beaux à n'importe quelle résolution.
Il serait vraiment logique de simplement réutiliser ces svgs animés dans Flutter afin que la cohérence puisse être correctement obtenue au lieu de réimplémenter des images et des animations !

SVG existe déjà, fonctionne et est largement disponible, utilisé et pris en charge partout ailleurs. Concentrez-vous là-dessus, c'est ce dont nous avons besoin.

Ce problème concerne la création d'un nouveau format vectoriel

Vous voulez dire que ce numéro consiste à réinventer la roue, n'est-ce pas ? Je suis d'accord avec @d-silveira - il vaut mieux ajouter un support intégré et approprié pour svg, nous n'avons pas besoin d'un nouveau format vectoriel.

Oui, il s'agit d'inventer une meilleure roue. SVG est déjà pris en charge dans Flutter en utilisant flutter_svg.

Mieux vaut pouvoir importer des svg et les traiter en interne, soit au moment de la construction, soit générer automatiquement du code lors de l'importation. Similaire à Android natif - vous pouvez importer svg et la définition de chemin Android xml sera générée à partir de la source svg. L'importation dans le projet Flutter pourrait générer un code de fléchette à réutiliser pour dessiner un élément vectoriel.

@Hixie est bon pour améliorer les choses, je n'en parlerai pas, mais comment pouvons-nous prendre en charge certains widgets qui n'autorisent que des images non svg en attendant ? (par exemple ceux avec des propriétés d'arrière-plan)

Ce serait une demande de fonctionnalité pour flutter_svg.

@Hixie Flutter SVG pourrait y créer une image, mais ce serait bien si le cadre était plus tolérant pour prendre des photos plutôt que des images dans certains cas. Déposé https://github.com/flutter/flutter/issues/49712

flutter_svg

Pourquoi donc? Ce n'est pas du tout lié au package flutter_svg :

CircleAvatar(
  backgroundImage: MySVGImage(),
)

@Hixie flutter_svg ne fonctionnera que dans certains cas. Permettez-moi de vous donner un exemple pratique : j'ai besoin de consommer une API REST qui, dans certains de ses points de terminaison, renvoie des URL d'images. Les images sont générées par l'utilisateur dans un backoffice, donc certaines d'entre elles sont png, certaines sont jpg et certaines sont svg. Le backoffice n'inclut pas l'extension de fichier dans l'URL et ne prend pas en charge HEAD, nous n'avons donc aucun moyen de connaître le type d'image à l'avance.
Le comportement attendu de flutter serait de recevoir l'url dans image.network et de la gérer, au lieu de me forcer à sauter à travers des cerceaux pour deviner de quel type d'image il s'agit, et si c'est svg passer à flutter_svg.
Tout cela ne tient même pas compte du fait que le flutter_svg n'est pas un remplacement instantané de l'image dans tous les cas ! :p

SVG en général ne fonctionnera que pour certains cas d'utilisation. :-)

Ce problème spécifique concerne le fait d'avoir un format graphique vectoriel non-SVG. Si vous avez une exigence différente, je vous recommande de la classer en tant que problème distinct.

De la discussion précédente, certaines considérations importantes sont:

• Nous ne voulons pas de support SVG complet. Il y a trop de choses dans la spécification qui sont chères, lourdes et/ou dupliquent ce que nous avons déjà dans Flutter.
• Nous devons souligner dans notre format pris en charge que ces opérations sont efficaces/efficaces/optimisées dans notre moteur graphique (Skia).
• Nous pouvons vouloir traiter le format au moment de la construction plutôt que de prendre en charge un interpréteur d'exécution complet.

Alors, comment fait-on pour créer un nouveau format vectoriel d'images optimisées pour le flottement ? D'après ce qui précède, je pense que c'est ce qui est suggéré...

Peut-être que les gars de Rive peuvent créer une bibliothèque de conversion SVG. Ils ont déjà un moteur vectoriel propriétaire (et open source) pour Flutter. @luigi-rosso

Pourquoi ne pas ajouter la prise en charge de l'importation de svg dans le projet Flutter. Et convertir en code de fléchette/nouveau vecteur dessinable, etc. Notez que la même situation est sur Android natif, c'est pourquoi nous n'utilisons pas svg directement (ce qui, je suis d'accord, n'a pas beaucoup de sens) et importons au projet à la place, svg est dépouillé de fonctionnalités non prises en charge et non nécessaires et converties en définition de chemin Android.

N'est-ce pas une bonne idée pour Flutter ?

@ giaur500 Ce problème ne concerne pas cela. Si vous avez une suggestion concernant spécifiquement SVG, veuillez déposer un problème séparé.

Pour être juste, de nombreux commentaires dans ce numéro traitent de SVG et de Flutter.

suivre

SVG est parfait pour une excellente interface utilisateur au niveau des pixels. Correctement le meilleur jusqu'à présent pour de grands pixels.

@lukepighetti Oui. Ils sont malheureusement tous hors sujet et les avoir ici n'apportera aucune amélioration à Flutter.

De la discussion précédente, certaines considérations importantes sont:

• Nous ne voulons pas de support SVG complet. Il y a trop de choses dans la spécification qui sont chères, lourdes et/ou dupliquent ce que nous avons déjà dans Flutter.
• Nous devons souligner dans notre format pris en charge que ces opérations sont efficaces/efficaces/optimisées dans notre moteur graphique (Skia).
• Nous pouvons vouloir traiter le format au moment de la construction plutôt que de prendre en charge un interpréteur d'exécution complet.

Un outil de temps de construction serait génial, prenez le vecteur et rendez toutes les densités d'écran, et ajoutez les actifs sous forme d'images. Apples iOS le fait avec des icônes PDF.

Mieux vaut pouvoir importer des svg et les traiter en interne, soit au moment de la construction, soit générer automatiquement du code lors de l'importation. Similaire à Android natif - vous pouvez importer svg et la définition de chemin Android xml sera générée à partir de la source svg. L'importation dans le projet Flutter pourrait générer un code de fléchette à réutiliser pour dessiner un élément vectoriel.

je l'aime bien

@ giaur500 Ce problème ne concerne pas cela. Si vous avez une suggestion concernant spécifiquement SVG, veuillez déposer un problème séparé.

Un nouveau problème a été créé : https://github.com/flutter/flutter/issues/63752

Alors, quel est l'état de ceci?
Y a-t-il une quelconque intention de prendre en charge quelque chose de similaire à VectorDrawable, ou même VectorDrawable lui-même pour ceux sur Android ?

En tant que développeur envisageant d'adopter l'écosystème, je dirais que c'est un point fort qui me convaincrait de rester natif.

Je ne l'ai jamais essayé moi-même, mais flutter svg lib avait un support pour au
les caractéristiques les moins clés du vecteur dessinable comme les chemins.

Le samedi 15 août 2020, 19:46 n00bmind, [email protected] a écrit :

Alors, quel est l'état de ceci?
Y a-t-il la moindre intention de soutenir quelque chose de similaire à
VectorDrawable, ou même VectorDrawable lui-même pour ceux sur Android ?

En tant que développeur envisageant d'adopter l'écosystème, je dirais que c'est un
point fort qui me convaincrait de rester natif..

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/flutter/flutter/issues/1831#issuecomment-674375846 ,
ou désabonnez-vous
https://github.com/notifications/unsubscribe-auth/ABI4Y4LWYSYEIWI3RRSSCK3SAZKO5ANCNFSM4B3FXMMQ
.

Je suppose que l'état n'est rien. Aucune conclusion n'existe ici à partir de ce fil et aussi mon idée de développer quelque chose de similaire au vecteur natif drawable fermé immédiatement.

Y a-t-il une raison pour laquelle le package flutter svg ne fonctionnera pas pour vous ? Nous l'utilisons avec beaucoup de succès dans l'une de nos applications. Je n'ai jamais utilisé Vector Drawable donc je ne sais pas comment il se compare à SVG.

Il semble que le package flutter_svg vaut le détour pour ce type de cas d'utilisation.
@lukepighetti comment évaluez-vous ses performances ? Mon utilisation serait juste une image de démarrage et quelques graphiques de la taille d'une icône ici et là dans l'application, donc rien d'extraordinaire.

Il semble que le package flutter_svg vaut le détour pour ce type de cas d'utilisation.

@lukepighetti comment évaluez-vous ses performances ? Mon utilisation serait juste une image de démarrage et quelques graphiques de la taille d'une icône ici et là dans l'application, donc rien d'extraordinaire.

Je lui donnerais une note très élevée pour votre cas d'utilisation. Je pense que les gens devraient vraiment essayer avant de faire pression sur l'équipe Flutter pour qu'elle fasse quelque chose en interne.

@lukepighetti

avant de faire pression sur l'équipe flutter pour qu'elle fasse quelque chose en interne.

Le vrai problème avec ce problème particulier est que Skia, le moteur graphique flutter, a tout ce qu'il faut pour faire fonctionner le format vectoriel "drawable" à la vitesse la plus élevée sans importer un paquet de fléchettes assez lourd qui appelle le moteur pour dessiner les primitives étape par étape.

Je pense que les gens devraient vraiment essayer _(paquet svg)_

Je pense que les gens devraient appeler bruyamment et dans tous les endroits possibles les Googlers à ce problème gh, car maintenant - après quatre ans - seules les relations publiques négatives peuvent donner un coup de pied à quelqu'un chez Google pour se demander si le cadre mobile de l'année 2020 devrait vraiment nous forcer à porter tous ces mégaoctets de graphiques raster dans nos applications.

[@Hixie]

À moins qu'il ne me manque quelque chose, l'implémentation d'une telle fonctionnalité de flottement ressemblerait beaucoup au package flutter_svg de @dnfield qui semble résoudre le cas d'utilisation que vous décrivez. En plus de cela, le mainteneur fait partie de l'équipe principale de Flutter afin que nous puissions être sûrs de sa qualité. Vous sentiriez-vous mieux si ce paquet était dans https://github.com/flutter/plugins ?

S'il y a quelque chose qui me manque, n'hésitez pas à me renseigner afin que je puisse en savoir plus sur ce sujet.

@lukepighetti

Je pense que "pas SVG" dans le titre du numéro devrait être mis en rouge, en gras et clignotant.

Ce problème ne concerne spécifiquement pas le format svg.

OP (et moi) avions l'espoir d'exposer l'api de chemin de Skia afin que les graphiques des actifs puissent être représentés sous une forme compacte - c'est-à-dire binaire d'endianess fixe. Dan a même fait un patch pour Skia qui fonctionne pour le flutter_svg, qui à son tour nous permet maintenant d'utiliser des assets svg. Bien que nous analysions toujours xml au moment de l'exécution de l'application et que nous dessinions en appelant le moteur - également pour les ressources statiques regroupées dans l'apk.

Avec une prise en charge appropriée du format vectoriel dessinable personnalisé (nommons-le fvd ), l'analyse du travail du concepteur se produirait une fois - au moment de la construction de l'application, puis l'objet au format fvd serait lancé directement sur Skia. Dans les applications à forte densité graphique, une telle approche aurait un effet énorme sur la taille de l'application et des économies notables sur le temps de rendu. [ se citant ]

J'espère que ce qui précède montre comment je vois ce problème et justifie mon appel à le faire enfin.
Même dans le cadre de la bibliothèque flutter_svg.

Flutter mérite d'avoir un avantage supplémentaire sur les technologies concurrentes.

Pour ce que ça vaut, il n'y a rien de mal à utiliser flutter_svg, c'est juste qu'il manque même des choses très simples, par exemple, il ne prend pas en charge les pourcentages et se bloque directement lorsque vous essayez de les rendre. Ce commentaire n'est pas un coup sur la bibliothèque flutter_svg, c'est juste pour expliquer aux gens qui disent que nous pouvons simplement utiliser flutter_svg.

flutter_svg semble très bien fonctionner malgré le fait qu'il ne supporte pas les scripts, HTML, SMIL, etc.

ça a l'air bien et nous pouvons construire du SVG à partir de fichiers, de réseaux ou de chaînes ordinaires.