Outros pensamentos aleatórios (nem todos meus):

• Realmente queremos evitar o suporte a um formato em que há uma expectativa preexistente de implementação de recursos que não serão de alto desempenho. Por exemplo, a implementação do SVG levará as pessoas a esperarem suporte completo ao SVG, incluindo scripts, HTML, SMIL, etc.
• Devemos projetar nosso formato explicitamente alinhado com os recursos de desempenho do Skia, por exemplo, drawAtlas.

O suporte a vetores parece crucial para uma estrutura de aplicativo que oferece suporte a vários tamanhos e densidades de tela. Caso contrário, você acabará com ícones que se parecem com isso:

Em vez disso:

@HansMuller

Kris mencionou isso também: poderíamos fazer algum processamento SVG limitado em tempo de compilação. Por exemplo, podemos gerar Widgets de ícone MD com base nas descrições SVG. Se feito com cuidado, isso pode economizar espaço e aumentar a fidelidade aos designs originais.

Para ícones de design de material especificamente, devemos investigar o uso da fonte de ícone de design de material.

@appsforartists Pelo que vale, nem Cocoa nem android.view usam formatos vetoriais para ícones.

@abarth Não me surpreende sobre o iOS - parece que eles começaram com uma tela codificada de 3,5" e tentaram muito manter esse modelo mental/simplicidade de resoluções suportadas desde então (veja: a largura de cada iPhone é a mesma ou o iPad e o iPad mini originais com a mesma resolução) Eu não sei muito sobre desenvolvimento móvel, mas isso é um pouco surpreendente sobre o Android não ser baseado em vetores.

De qualquer forma, os ícones não devem ter alias como na captura de tela acima, e os vetores são uma boa solução para independência de resolução. Como vocês escolhem implementar para resolver ícones bonitos é com vocês. :risonho:

Como vocês escolhem implementar para resolver ícones bonitos é com vocês.

Você estaria disposto a registrar um problema separado sobre o problema de resolução que você estava vendo com ícones? A @krisgiesing implementou um resolvedor de ativos com reconhecimento de resolução que lida com muitos casos. Seria valioso aprender sobre os casos que não trata.

Estou pensando em adicionar alguns testes para o suporte de reconhecimento de resolução atual, então agora seria um ótimo momento para entender se algo não está funcionando corretamente.

Parece que o 3x tem uma proporção de pixels do dispositivo de 2.6 , para a qual provavelmente não temos um recurso.

Estou analisando este caso específico agora. A proporção de pixels do dispositivo é 2,625; estamos escolhendo o ativo 3,0x, o que é esperado. No entanto, algo parece estar acontecendo durante a renderização que está causando algum tipo de artefato extra de alias. Portanto, embora @abarth tenha corrigido o caso dos ícones do Material Design mudando para uma fonte, ainda estou investigando em nome de outros tipos de ativos de imagem que precisam de dimensionamento dependente da resolução.

Vou abrir outro bug para rastrear isso, pois é tangencial ao suporte de um formato vetorial.

Veja #2337

O Android suporta o formato "VectorDrawable", que é apenas um subconjunto de SVG com bom desempenho. Espero que você considere usar o mesmo formato, já que ele já tem algum suporte da comunidade e a equipe do Android aparentemente considerou seu desempenho adequado.

O VectorDrawable certamente é influenciado pelo SVG, mas não é um subconjunto. Além disso, ele usa XML, o que praticamente garante que não será o formato vetorial com melhor desempenho que alguém poderia criar. :-)

Foi errado descrever VectorDrawable como um subconjunto estrito, mas ainda parece ser um compromisso equilibrado entre garantir um bom desempenho de _render_ e facilidade de uso. A especificação VectorDrawable frequentemente segue a especificação SVG para áreas-chave, como sintaxe de dados de caminho, tornando muito mais fácil converter ativos SVG que muitos desenvolvedores já usam e compartilhar VectorDrawables que os aplicativos Android existentes já contêm.

Não consigo imaginar que o XML seja um bloqueador de desempenho significativo porque afeta apenas a análise. Parece-me que o desempenho de _render_ - o tipo de desempenho que afeta o objetivo do Flutter de aplicativos de 60 fps - é mais dependente do conjunto de operações vetoriais que o Skia terá que desenhar, não uma etapa de análise que pode ser feita uma vez e armazenada em cache.

Não quero insistir, mas não posso deixar de sentir que o trabalho para isso já foi feito e, portanto, não precisa ser arquivado no marco "após o lançamento 2.0".

Acabamos usando a fonte do Material Design para os ícones do Material Design. Não estou ciente de nenhum obstáculo que impeça alguém de construir isso em cima do Flutter hoje usando chamadas diretas dart:ui ou um widget CustomPaint: https://docs.flutter.io/flutter/widgets/CustomPaint-class. html. Não temos planos imediatos para construir tal neste momento.

$.02 - mesmo navegadores instáveis ​​( e framework concorrente React Native não importa, sua solução é hacky) pode renderizar SVG. A opção de exportação de imagem requer a criação de um mínimo de 3 arquivos para cada ícone ou recurso de arte para minha equipe. Essa é uma prática ruim em comparação com um arquivo SVG que pode ser exibido em qualquer resolução.

Para o comentário acima de Hixie, as expectativas pré-existentes não devem inibir a implementação de um recurso que vale a pena. Prefiro ter suporte básico para exibição SVG (que resolve muitos problemas para mim e minha equipe) e descobrir que opções estendidas não estão disponíveis do que confiar em um número cada vez maior de PNGs para acomodar o crescente número de resoluções de tela.

Estou voltando a criar uma fonte para minha equipe, mas isso não é tão bom quanto o suporte SVG nativo porque o formato da fonte adiciona formatação extra para altura de linha e espaçamento entre letras que precisa ser ajustado no aplicativo. Além disso, as fontes querem ser exibidas em resoluções fixas (12px, 16px, 20px, 36px...), o que também é limitante.

Obrigado pela estrutura legal do Flutter. :)

Eu encorajaria qualquer pessoa que queira suporte SVG a implementar o suporte SVG como um pacote Dart para Flutter.

Para os interessados, eu indicaria https://docs.flutter.io/flutter/dart-ui/dart-ui-library.html que é a biblioteca de baixo nível para desenho.

Da equipe: A biblioteca Dart não é uma solução boa o suficiente. Só passando.

Você pode detalhar isso? Todo o framework do Flutter é uma biblioteca Dart; qualquer coisa que implementarmos aqui provavelmente será uma biblioteca Dart. Quais são os requisitos para "bom o suficiente"?

Caso em questão, implementei um analisador SVG (simples e não exaustivo) no pure-Dart há algum tempo:

https://github.com/matanlurey/svg

Provavelmente seria um pouco trivial para:

uma. Crie um SVG de tempo de execução -> SvgRenderElement , que usa dart:ui nos bastidores.
b. Crie uma etapa de compilação em tempo de compilação que converta um SVG em algo como:

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

@deborah-ufw se tiver interesse, adoraríamos conversar para saber mais. Você pode me enviar um e-mail?

Oi Seth, matanlurey e Hixie - muito obrigado pela resposta. Provavelmente não sou a pessoa certa para conversar em profundidade, já que foram nossos engenheiros líderes que rejeitaram a solução do plug-in Dart (levando assim à geração de uma enorme biblioteca de png's para nosso aplicativo, o que também faz a maioria de nós estremecer).

Eu gostaria de passar o link para este problema do Github para eles e pedir-lhes que contribuíssem com razões técnicas para seu comentário (que foi feito de forma mais colorida do que eu passei) - farei isso assim que terminar de digitar.

Eles também podem conversar com nossos engenheiros diretamente via http://gitter.im/flutter/flutter, bem como outros métodos de contato listados https://flutter.io/support/, se necessário. :)

Vou adicionar isso. Obrigado! :D

Outra abordagem é integrar algo como http://svgpp.org/ no nível nativo e usar o sistema de plugins Flutter para se comunicar com ele. Isso provavelmente lhe daria as melhores características de tamanho/desempenho para suporte completo a SVG, mas às custas de manter uma dependência.

Que tal procurar suporte SVG no nível do mecanismo? Não acho razoável ou desejável esperar suporte total do padrão, mas parte do apelo é o suporte para equipes multifuncionais e ferramentas existentes.

Tenho a impressão de que o Skia fornece algum suporte básico a SVG. Não há como disponibilizar isso para o Flutter?

Pelo que posso dizer, tem sido apenas experimental e parcial. Há um problema aberto aqui https://bugs.chromium.org/p/skia/issues/detail?id=5596 bit tem mais de um ano. Eles também estão listando em seu roteiro, mas novamente não estão claros qual prioridade.

Não faria sentido oferecer suporte a SVG no nível do mecanismo porque isso não exporia o modelo de documento SVG, que é uma parte essencial do suporte a SVG.

Se o Flutter suportar SVG, será com o objetivo final de realmente suportar SVG real. É contra a filosofia do Flutter ter implementações de recursos sem entusiasmo.

Não vejo a exposição do modelo de documento SVG como parte central do suporte a SVG. Seria bom ter, mas não obrigatório para os casos de uso que tenho em mente.

Sim, o suporte no nível da biblioteca permitiria mais recursos - mas se o próprio mecanismo fosse capaz de renderizar (um subconjunto significativo de) dados SVG, isso provavelmente seria suficiente para permitir a renderização de ativos de imagem vetorial definidos por esse subconjunto de SVG.

Este problema é claramente maior do que isso, mas eu ficaria feliz em pegar os ativos SVG existentes e renderizá-los adequadamente em diferentes resoluções sem convertê-los em imagens raster volumosas.

Sim, a importação de arquivos de ativos SVG seria muito bom, mas a especificação para SVG tem mais de 800 páginas. Dito isto, apenas importar arquivos estáticos para renderizar no Skia (que é uma biblioteca de gráficos vetoriais) não deve ser um problema. Então eu estou assumindo; como sempre, só posso trabalhar meio período nos finais de semana para que você não veja as coisas imediatamente. Também tenho uma tonelada de arquivos SVG, mas todos eles usam as mesmas coisas (coleções de ícones do flaticon), então eu apreciaria arquivos SVG de amostra de pessoas que desejam esse recurso.

Carlos.

Eu tenho mexido nisso um pouco ao longo do tempo também. Aqui está o que eu inventei:

Implementação no nível do mecanismo

Isso parece atraente pelos seguintes motivos:

1. Em teoria, suporta algo como image: new AssetImage('graphics/background.svg') para ter algum código C/C++ analisado e traduzir os dados SVG para comandos de renderização Skia
2. Pelo menos um bom candidato por aí que deve ser capaz de se conectar ao Skia com bastante facilidade (https://github.com/svgpp/svgpp) no nível do mecanismo
3. A lógica SVG do WebKit seria incrível, mas parece ter muitas dependências
4. Eu não acho que librsvg portaria muito bem (fortemente acoplado ao Cairo, fazendo a transição para Rust como idioma principal - precisaria descobrir uma maneira de chegar ao Skia como um back-end, pelo menos)

Mas tem pelo menos algumas dificuldades:

• Manipulando corretamente o texto
• Manipulando corretamente o CSS (se for o caso? mas adicioná-lo não é uma tarefa simples)
• Estender o suporte para recursos adicionais (ou permitir que os usuários adicionem suporte para recursos com mais facilidade) é um desafio.
• Parece ser muito difícil lidar com animações

Implementação de nível de dardo

1. O dart:ui do Flutter oferece muitos dos primitivos do Skia que o SVG já precisa
2. Suspeito que a renderização de texto seria muito mais fácil de lidar neste nível do que no nível do mecanismo
3. Deve ser mais fácil para mais da comunidade manter/estender
4. Deve ser capaz de lidar de forma mais barata com a interação direta com a lógica de análise (talvez para lidar com exceções e/ou animações?)

Mas tem algumas dificuldades:

• Pode não fazer muito melhor suporte a CSS
• Pode não fazer animações de suporte muito melhores
• Provavelmente seria mais lento (mas talvez não o suficiente para importar, e poderia ser compensado pelo código SVG para Dart compilado AOT)

Dados de teste

No que diz respeito aos SVGs de amostra, provavelmente seria mais útil identificar quais SVGs são suportados no conjunto de testes 1.1 (ou, se parcialmente suportado, o que eles são parcialmente suportados). Esses podem ser encontrados aqui:
https://github.com/w3c/web-platform-tests/tree/master/svg/import

Ou aqui com algumas comparações com PNG: https://www.w3.org/Graphics/SVG/Test/20110816/

@cbazza , de que maneira você está pensando em implementar isso? Neste ponto, estou mais inclinado para uma implementação no nível do pacote Dart.

Além disso, acho que o suporte ao tipo de ícone provavelmente é facilmente manipulado com algo como IconData. Pode ser melhor tratar isso separadamente, pois provavelmente só teria que dar suporte a um único caminho por codepoint

Estou pensando em 'implementação no nível do Dart' em cima do dart:ui.

2 casos de uso básicos:

(1) carregue arquivos svg de ícones estáticos com algo como seu
"image: new AssetImage('graphics/background.svg')", onde o
arquivo pode vir do sistema de arquivos ou pela rede
dinamicamente.

(2) Suporte svg baseado em widget com DSX (construção semelhante a JSX)
que seria muito semelhante a:
https://github.com/react-native-community/react-native-svg

Em relação a 'Dados de teste', preciso de arquivos reais de pessoas que precisam
isso e não o conjunto de testes w3. O suporte a SVG dependeria
sobre o que o dart:ui suporta, se um arquivo svg desejado contiver
coisas que não podem ser feitas com dart:ui , eu seria capaz de
descubra rápido.

Carlos.

Eu não acho que devemos ir para o modelo SVG nativo de reação. Fico querendo dar suporte a casos da vida real, mas acho que cobrir o pacote w3 nos daria uma base melhor do que funciona e do que não funciona e quão desafiador seria implementar)

OK, parece haver algum mal-entendido...
Quando eu fizer (1), ele pegará arquivos SVG padrão e tentarei suportar o máximo que puder, dado o dart:ui (Skia).
Quando eu fizer (2), que é criar widgets para lidar com construções como SVG, ele será muito semelhante à biblioteca react-native-svg. São 2 coisas bem diferentes.

@cbazza o caso de uso para svgs em nosso aplicativo é principalmente para svgs de uma cor que usamos como ícones. Aqui está um link para um arquivo zip no Dropbox com uma seleção de svgs recentes que são representativos. https://www.dropbox.com/s/dp38wxc22625cvc/icons.zip?dl=0

Obrigado pelo interesse em ajudar aqui, ficaria feliz em ver um plugin SVG Flutter ganhando vida!

Eu escrevi uma ferramenta que faz uma análise mínima de uma sequência de arquivos um pouco SVG e despeja arquivos Dart que mais tarde usamos para mostrar animações de ícones: vitool .

Usei essa ferramenta para criar os dados do AnimatedIcons , você pode conferir o resultado executando o app de teste manual ( cd dev/manual_tests; flutter run -t lib/animated_icons.dart ).

Está longe de ser ideal ou completo, mas funciona para o conjunto atual de ícones animados que temos, e alguém deve se sentir capacitado para fork/estendê-lo.

@deborah-ufw para esses ícones de cor única, algo que você pode fazer é criar uma fonte de ícones e mostrar os ícones usando o widget Icon .

@amirh não parece ser fácil criar fontes vetoriais coloridas

@amirh se você ler todo o tópico acima, criar e definir uma fonte com glifos como ícones é uma série extra de etapas que devem ser executadas porque o SVG não é suportado. O suporte SVG é muito mais eficiente do que uma fonte. Além disso, zoechi está certo - qualquer arte vetorial que tenha várias cores é quase impossível de transformar em uma fonte.

Desculpe - eu olhei para os ícones de amostra e pensei que você só precisava de ícones de cor única.

@deborah-ufw, obrigado pelos arquivos, exatamente o que eu estava procurando e já encontrei coisas que meus arquivos não possuem.

@amirh , sim, eu já vi seu ótimo trabalho ;)

Finalmente temos uma maneira direta de fornecer um svg ou xml de ativo vetorial na imagem para flutter

@ Hixie : por favor, (re) considere que, para equipes móveis nativas multiplataforma, esse é um ponto de dor real, mas que apenas suporte SVG parcial e relativamente simples é necessário para resolver isso. Para os mantenedores do padrão SVG, isso pode ser considerado indiferente, mas o Flutter é para desenvolvedores móveis, não para autores de padrões gerais. O Flutter conquistaria os corações dos desenvolvedores móveis se aliviasse sua dor muito real, mesmo que apenas de maneira pragmática.

Considere também que, apesar dessa necessidade existente há muito tempo, a abordagem de suporte da comunidade falhou em produzir soluções viáveis ​​no concorrente do Flutter Xamarin (nos meus 5 anos de experiência em Xamarin - libs não podem lidar com exportações de ferramentas de design, são muito limitadas, não estáveis, pago e/ou fonte fechada).

Por isso, não estou otimista de que a comunidade Flutter terá sucesso onde a comunidade Xamarin falhou. Eu estimo que um prático. suporte parcial para ícones SVG é algo que a equipe do Flutter poderia oferecer, usando primitivos Skia existentes.

Isso se encaixaria bem no objetivo do Flutter : permitir que os desenvolvedores móveis forneçam UX bonito e de alto desempenho em tempo recorde . Isso melhoraria a produtividade, fidelidade e desempenho (um SVG carrega muito mais rápido do que todos os PNGs; ícones SVGs normalmente têm um custo computacional modesto porque um requisito de clareza visual muitas vezes leva a uma forma de complexidade modesta).

A necessidade principal é um fluxo de trabalho produtivo, desde ferramentas de designer criativas comumente usadas (como Adobe) até ícones de aplicativos nativos escaláveis.

A abordagem PNG atual é um grande desperdício em termos de produtividade e tamanho do aplicativo; é tão primitivo gerar e enviar cada ícone em até 9 bitmaps fixos (6 Android, 3 iOS) que são então pós-processados ​​em tempo de execução. O problema aumenta constantemente à medida que as resoluções aumentam em tamanho e variação.
Ele se destaca como um polegar dolorido na experiência de desenvolvedor Flutter inovadora e produtiva, de outra forma deliciosa. Acho que Flutter tem uma oportunidade real de conquistar corações e mentes de desenvolvedores aqui,

Além disso , @dnfield, os recursos SVG mencionados acima que são mencionados como obstáculos para a implementação no Flutter, na minha experiência, não são relevantes ou são raros o suficiente para que voltar aos PNGs para esses ativos de design seja um pequeno inconveniente.
Não importa: CSS, HTML, SMIL, Modelo de Documento, scripts
Animação, Texto: raro o suficiente para recorrer a outras tecnologias para isso

Espero que a extensão deste comentário transmita quanto valor uma solução teria. Hth!

@VincentH-Net Estou 100% com você porque também sinto a dor !!! Por favor, envie-me alguns de seus arquivos SVG. Talvez o Xamarin tenha lutado para fornecer suporte a SVG devido à falta de um mecanismo de gráficos vetoriais que pudesse lidar com isso; este não é o caso do Flutter com Skia, então estou muito otimista de que uma solução da comunidade acontecerá.

FWIW, Xamarin também tem Skia disponível em SkiaSharp. SVG pode ser complicado mesmo para implementação mínima.

Mas @cbazza eu estaria muito interessado em colaborar com você nisso

E na frente de animação, acho que habilitar o Lottie satisfaria muitos casos de uso (e provavelmente faria isso com melhores ferramentas para designers).

@dnfield Acho que essas animações Lottie podem ser facilmente reconstruídas como widgets Flutter

@dnfield , excelente, você pode ser o cara de baixo nível manipulando as alterações no nível do mecanismo enquanto eu faço o trabalho de nível superior no widget (análise svg assíncrona, construção de 'imagem' que pode ser armazenada em cache e enviada para tela em atualizações de renderização, etc).
sim, o trabalho de Lottie seria ótimo para o fluxo de trabalho do designer/desenvolvedor.
@zoechi por que reconstruir algo manualmente com widgets quando você pode simplesmente importar um widget Lottie funcional que lida com tudo para você? Tendo dito que meu objetivo anterior (2) acima funcionaria muito bem com animações de widgets (daí porque eu quero fazer isso também).

@zoechi - o objetivo seria permitir que os designers criassem essas coisas e as renderizassem com o mínimo de esforço por parte do desenvolvedor. Um objetivo secundário seria permitir carregá-los como recursos em tempo de execução, em vez de exigir pré-compilação.

O mesmo vale para SVG - sim, um desenvolvedor certamente poderia converter dados vetoriais SVG para Dart, mas idealmente você pode simplesmente incluir um recurso de desenho vetorial (SVG ou não) e renderizá-lo em tempo de execução.

Em outras palavras, quero poder dizer ao meu designer para criar um ativo vetorial uma vez e poder usá-lo no meu aplicativo Flutter com modificação mínima (e sem que o designer o exporte 5 vezes em vários formatos raster que acabarão sendo inválido assim que a Apple ou a Samsung lançarem seu próximo telefone).

vários formatos raster

sim, isso parece a década anterior

https://github.com/luberda-molinet/FFImageLoading Pode valer a pena olhar, usa Skia para renderizar SVG para Xamarin

@escamoteur

Obrigado, isso parece muito bom, a única coisa que falta é que não é assíncrono ;)

Estou usando apenas drawables vetoriais no aplicativo Android recentemente e não vejo nenhuma penalidade de desempenho perceptível. Os ícones são nítidos e o tamanho do aplicativo é muito menor. Também é muito mais fácil e rápido testar imagens diferentes. Esta solução @2 , @3 , @4 , @5 ,.... parece um grande retrocesso em um framework tão moderno quanto o Flutter.
Não entendo por que você simplesmente não pode ir até a equipe responsável pelos drawables vetoriais do Android e usar suas ideias ou implementação (se possível) para resolver esse problema.

Eu estive brincando com alguns SVGs sendo desenhados em uma tela aqui. Os elementos path são provavelmente os mais difíceis de implementar, mas existe uma API Skia que realmente ajudaria se exposta. Eu experimentei expô-lo no motor e abrirei um PR assim que tiver um pouco mais de tempo para refiná-lo.

A ideia aproximada seria algo que nos permitisse criar um dart:ui Path partir de uma string de dados SVG, usando a API Skia já existente para fazer isso. O método proposto é static Path Path.parseFromSvgData(String svgData) -> Path

Isso ainda deixa algum trabalho em torno da análise das várias transformações/traços/preenchimentos que podem ser aplicados. Acho que podemos pegar emprestado uma boa quantidade disso do trabalho que @amirh fez (não peguei emprestado toda a lógica de análise de caminho porque parecia que poderia ter restrições que o SkParsePath não tem e, como o SkParsePath, deve ser mais eficiente, pois exigirá apenas uma viagem de ida e volta para o lado nativo para desenhar o caminho em vez de viagens de ida e volta para cada comando de desenho). Também não acabei usando @matanlurey por motivos semelhantes.

Veja https://github.com/flutter/flutter/blob/master/dev/tools/vitool/lib/vitool.dart , https://github.com/dnfield/flutter_svg (que atualmente é capaz de renderizar os dois SVGs incluído nesse projeto para uma tela) e https://github.com/dnfield/engine/tree/path_svg (que atualmente também inclui meu trabalho relacionado ao PathMeasure/PathMetrics para Lottie).

Olá @dnfield ,

Aqui está minha opinião sobre sua implementação inicial. Deixe-me apenas dizer que o que eu vou dizer não deve fazer diferença para o seu entusiasmo e progresso de codificação. Quanto mais você fizer melhor, porque sempre podemos usá-lo mais tarde.

O problema que tenho é arquitetônico e aqui está o porquê. Para que a interface do usuário seja responsiva a 60 quadros/s, cada quadro tem apenas ~ 16 ms para ser executado antes de bloquear a interface do usuário. Então, vamos supor que metade é usada pelo Flutter para fazer isso, que deixa 8ms para o nosso analisador SVG e não há como analisar qualquer arquivo SVG e gerar imagem nesse período, não importa o quão poderoso seja um telefone/tablet que você tenha. Então, a melhor coisa a fazer é direcionar dispositivos lentos e ter um código assíncrono que seja capaz de fazer isso usando vários quadros, mas a chave é que cada quadro só pode ser executado até 8 ms e, em seguida, deve retornar e pegar no próximo quadro.

Portanto, você não pode analisar o XML usando dart:xml porque não é assíncrono, ele bloqueará até que todo o arquivo seja analisado. A geração da imagem também deve ser assíncrona porque você não pode fazer tudo em 8ms. Não faz sentido otimizar prematuramente o código, portanto, escreva o melhor código que pode ser lido. Eu tenho um plano que funcionará, mas levará algum tempo, então quero que você continue como está, porque sempre posso pegar seu trabalho e usá-lo mais tarde. Meu design se conecta à funcionalidade de carregamento de imagem atual (AssetImage e NetworkImage) e o usuário só precisa especificar um '.svg' em vez de '.png'.

Carlos.

@cbazza apenas uma ideia: a análise pode ser feita de forma isolada. Acho que houve algum trabalho feito para poder se comunicar com canais de mensagens de isolados que não sejam o isolado da interface do usuário e passar dados entre isolados por referência em vez de copiar (não tenho certeza sobre status ou progresso)

@cbazza - obrigado. Não acho que dart_xml seja a melhor solução para isso, mas funciona e permite algum progresso na lógica de desenho (e eu não queria bloquear isso completamente enquanto trabalhava para implementar um analisador XML assíncrono). Também comecei a analisar a implementação de ImageProvider , mas acho que pode ser um detalhe de implementação que podemos ocultar dos usuários.

Não estou de forma alguma definido em qualquer uma dessas APIs. Mas podemos pelo menos começar a desenhar SVGs e provavelmente suportar os simples em telefones decentes.

Você pretende trabalhar na API de leitura/análise de XML/SVG?

@zoechi - ainda poderíamos obter um uso de memória muito melhor e provavelmente melhor tempo de análise com um modelo de leitor de streaming.

@zoechi sim, eu olhei para isolados, mas você só pode passar valores primitivos (null, num, bool, double, String) e listas e mapas, e não objetos e/ou árvores de objetos, então a rota assíncrona parecia melhor. Outra coisa interessante sobre descobrir a análise xml assíncrona é que os conceitos se aplicariam a qualquer processamento de árvore assíncrona, como, por exemplo, o widget ou a árvore de elementos. Isso permitiria a reconciliação assíncrona, por exemplo, como na fibra do React :)

@dnfield sim, estou trabalhando no analisador/processador xml/svg assíncrono.

apenas imaginando, renderizar SVG usando uma visualização da web pode ser uma opção?

Muito pesado para botões simples e não tenho certeza se o webview será capaz de lidar com alterações de 60 quadros/s. Quero dizer, digamos que movemos o ícone ou o dimensionamos, por exemplo.

Não sou desenvolvedor iOS, então vejo agora que também o iOS 11 tem suporte para ativos vetoriais . Não é SVG, mas PDF. É mais fácil oferecer suporte a ativos vetoriais PDF?

Não. O Quartz tem muitos vínculos históricos com o PDF em seu sistema de renderização interno, o que facilita fazer isso em um dispositivo iOS. Skia não é um renderizador de PDF, e o formato do arquivo (IMO) introduziria muita ambiguidade sobre o que é suportado e o que não é (com ferramentas não tão boas para corrigi-lo disponíveis).

PDF é mais complicado que SVG e o subconjunto PDF/X (que é usado para ativos vetoriais) é projetado para impressão. Eu adoraria ver o suporte de renderização de PDF no Flutter, mas para nós vamos nos ater ao SVG.

Eu ficaria feliz com o mero subconjunto VectorDrawable de svg (ponto, linha, curva, preenchimento, movimento). Flutter permite RAD e pretende ser verdadeiramente multiplataforma (com desktop chegando), mas agora não pode. As plataformas Android e Apple estão presentes em telas de 60"+ 4HD. Os gráficos vetoriais são obrigatórios.

PS Com licença, mas sem o VG, seu trabalho (equipe de vibração) desaparecerá após o Kotlin funcionar nativamente em muitas plataformas, incluindo iOS. Claro que o nativo do Kotlin ainda está em beta, mas o Flutter também. :(

@ohir Por favor, explique como você escreveria uma visualização de plataforma cruzada (código único) que funciona tanto no iOS quanto no Android com o Kotlin nativo. A menos que você pretenda fazer uma versão kotlin da abstração de widget nativa do react?

Não vamos subestimar o que os nativos de Kotlin farão porque as possibilidades são infinitas. Eu cheguei ao Flutter dos meus experimentos criando algo como o Flutter usando o Cocos2d-x. Eles poderiam usar isso também e/ou React Native e/ou Flutter porque tudo é de código aberto e está disponível para polinização cruzada :)

Sim, concordo totalmente, o amor e a adoção do kotlin pelos desenvolvedores é enorme e a compilação entre plataformas torna as possibilidades infinitas. Mas a comparação entre o Flutter beta e o Kotlin beta nativo para plataforma cruzada móvel hoje é inútil.
Enfim, desviando do assunto.

@lukaspili Até agora, há anko para Android. Seus layouts DSL podem funcionar intactos também com apko , linko e winko* incluídos na respectiva subárvore da plataforma. Mas isso é OT para a questão do Flutter VG. [* ainda não existe].

Obrigado por toda a conversa apaixonada! Gostaríamos de manter esse problema focado nos casos de uso e requisitos para formatos vetoriais e APIs. Obrigado antecipadamente por permanecer no tópico! :)

O que as pessoas acham de dividir isso em um problema para suportar SVG e manter este para algum formato vetorial de vibração TBD?

Isso teria sentido para mim; a edição original é formulada como um formato de vetor específico do Flutter de algum tipo.

@cbazza Hooray para suporte tipo svg. Eu tenho um monte de svgs sem ícones que eu uso basicamente para desenhar toda a interface do usuário de um aplicativo. Como devo enviá-los para você?

Adoraria tentar mudar para a vibração, mas gerar um zilhão de pngs vai inchar seriamente o tamanho do aplicativo e parecer feio.

sim, por favor me envie um URL para ver os arquivos.

Então, neste ponto, nesta frente, estou buscando uma abordagem baseada em Flatbuffer. Estou trabalhando na definição de um esquema Flatbuffer que possa capturar comandos de desenho vetorial - mais ou menos da mesma forma que o Skia captura caminhos.

Eu pude ver isso sendo semi-interoperável com SVG (por exemplo, ter uma ferramenta de conversão SVG -> Flatbuffer ou Android Vector Drawable XML -> Flatbuffer, que poderia cobrir muitos dos casos de uso de SVGs) e evitar muitos dos impactos de desempenho que nós 'd enfrentaria com SVG (falta de análise XML de streaming, precisa analisar os dados do caminho SVG e enviá-los para o nativo bit a bit). Também consegui produzir arquivos binários menores do que o formato SVG (embora ainda não se saiba o quão bem isso será dimensionado).

Também deve ser possível fornecer mais clareza nas ferramentas de conversão sobre quais recursos não são suportados em um determinado SVG (por exemplo, "ForeignElements não são suportados por este formato").

O bit de análise do Flatbuffer pode ser feito em Dart ou C++ - a única coisa no dart é que ainda seria bom ter alguma maneira de enviar comandos em lote para o Skia para construir caminhos e desenhar no Canvas.

existe uma solução potencialmente muito mais simples que é executar uma análise em tempo de compilação e um resumo das operações de nó SVG para Skia ...

@sandrobilbeisi você quer dizer como https://github.com/amirh/flutter/commit/69de4bbf3177d9766a386c55b27a12619da43a05 ?

isso é digno de nota ... e também há vitool https://github.com/flutter/flutter/blob/master/dev/tools/vitool/lib/vitool.dart

mas eu estava pensando mais como uma etapa de construção como a que o Xcode usa com ativos SVG para entregas iOS

@sandrobilbeisi você quer dizer criar bitmap de svgs durante o tempo de compilação?

BTW, o pacote Xamarin ffimageloading armazena em cache os bitmaps renderizados para renderização apenas uma vez. Ele também armazena em cache imagens de rede e imagens redimensionadas, o que o torna muito rápido

não bitmap , mas Skia que é originalmente um motor de gráficos vetoriais para < canvas >
https://skia.org/ ( ps adquirido pelo Google há uma dúzia de anos : http://www.satine.org/archives/2007/03/05/the-skia-source-code-dilemma/ )

Você quer dizer converter svg em um formato de imagem skia?

sim

@cbazza link para arquivos de teste SVG: https://github.com/slingshotapp/artwork

Existe uma maneira de executar o vitool no nível do projeto? Eu posso criar o arquivo gerado, mas ele precisa de acesso a muitas classes privadas que me impedem de adicionar o .g.dart ao meu projeto.

Referindo-se à ferramenta em <flutter>/dev/tools/vitool : #dart bin/main.dart --asset-name=_$hello --output=here.g.dart ./test_assets/horizontal_bar_relative.svg

@emilieroberts Obrigado, mas esses arquivos não estão no formato SVG, mas no formato vetorial personalizado do Android, que é muito semelhante ao SVG.

@cbazza oops, de fato - a maioria dos svgs estão lá agora :)

@cbazza você pode esclarecer o que quer dizer com vetor android personalizado? Eles têm uma tag <svg , ao contrário dos drawables vetoriais do Android.

O que quer que esteja sendo feito com o vitool no momento é incrível, mas não consegui encontrar um vestígio de documentação em nenhum lugar. Posso escrever um exemplo com AnimatedIcons.arrow_menu , mas também gostaria de saber o que seria necessário para fazer isso a partir de ativos de fora do SDK do flutter.

@fmatosqg você está certo, o código usado para executar as animações geradas pelo vitool é privado do framework. A razão é que ainda há questões em aberto sobre qual seria um bom formato vetorial para o Flutter (conforme rastreado nesta edição), e eu queria evitar uma API pública que suportasse qualquer formato específico (já que isso se comprometeria com esse formato se não queremos mudanças no futuro).
A superfície de API atual para AnimatedIcon nos permite usar arquivos gerados pelo vitool internamente no framework e ainda poder substituir a implementação subjacente e o formato vetorial sem quebrar nenhum cliente.

Se você quiser gerar arquivos com vitool e usá-lo em seu projeto, você pode fazê-lo copiando o código de packages/flutter/lib/src/material/animated_icons e incluindo-o como parte de seu projeto (isso também garante que seu projeto não quebrará se mudamos a maquinaria usada pelo AnimatedIcon).

Lamentamos o inconveniente e esperamos obter uma solução melhor em breve.

Eu gosto dessa ideia, especialmente se https://github.com/flutter/flutter/issues/13834 for para frente. Acredito que tal coisa não deve fazer parte de um SDK monolítico, mas não particularmente preocupado se for um pacote oficial ou comunitário.

Existe um formato compacto para subconjunto de svg cunhado para Shiny (Go desktop framework) por alguém no grande G . Sua representação binária e pode trazer o tamanho padrão do ícone do iniciador do Android abaixo de 100 bytes. Como dito acima no thread - e IMSO - vetores de desenho devem ser o dever de Skia, com Flutter passando uma representação mais compacta disponível. É o dever das ferramentas compilar os arquivos res/ svg para o formato interno.
[ @amirh Re: perguntas abertas sobre o que seria um bom formato vetorial ]

Então FWIW, em flutter_svg eu formulei o código de forma que todo o desenho seja realmente feito por objetos intermediários. O trabalho relacionado ao SVG é basicamente mapear SVG para esses objetos. Ainda há trabalho a fazer para estabilizar totalmente esse formato intermediário (por exemplo, comecei no suporte a texto, mas está muito ruim agora).

Comecei a portar o suporte para Android Vector Drawables na estrutura (menos o suporte para referências externas de cores e estilos etc., e ainda não suportando caminhos de clipe ou provavelmente alguns outros recursos). Deve ser totalmente possível suportar o Shiny dessa maneira também, ou realmente qualquer outro formato. Eu gosto de trabalhar com SVG neste momento porque ajuda a cobrir muitos casos interessantes para suporte, então esse é meu foco principal por enquanto.

Depois de ler este tópico - e um longo sobre suporte a JSX - não posso deixar de pensar que existe um problema de governança. A equipe do Flutter corre o risco de ser puxada em mil direções diferentes como o clamor do desenvolvedor pelo que _eles_ sentem ser importante. Talvez o Flutter devesse instituir projetos de "incubadora", como o Apache. Os recursos solicitados são implementados por plugins, de forma open-source, possivelmente com contribuições da própria equipe do Flutter. Se os plugins alcançarem suporte, eficácia e popularidade suficientes, eles se tornarão candidatos para inclusão na estrutura principal do Flutter.

Eu sinto que isso permitiria que os desenvolvedores mais vocais colocassem seu "código onde há boca" em vez de recorrer ao peito e à testa em exibição aqui, e deixaria a equipe do Flutter mais livre para se concentrar na engenharia principal.

Eu respeitosamente discordo. Se você olhar para os marcos como bucket5, saberá no que a equipe está trabalhando e, se for para bucket6, saberá o que eles consideram uma prioridade. Além disso, você pode saber o que eles não consideram urgente se observar outros marcos no caminho.

Além disso, a razão para ter algo adicionado ao núcleo do flutter deve ser mais do que "eu posso fazer um plugin e funciona para todos e todos querem". Essa é uma razão para criar um plugin, mas não o suficiente para ser adicionado a este repositório ou a outros repositórios de vibração.

Um exemplo de coisas que não deveriam ser plugins: coisas que @dnfield adicionou ao motor para que ele pudesse se beneficiar e usar o plugin que possui. Tal plugin não teria chance de fazer todos os recursos que faz se eles não fossem adicionados ao mecanismo.

Ser vocal é importante, mas nunca garantirá que isso aconteça. Colocar o código onde está a boca também é importante, mas ainda não é suficiente. Este projeto tem muita transparência e eles ouvem claramente o que os devs dizem, mas não é uma democracia e não significa que o voto popular vai ganhar sem raciocinar sobre as consequências.

Sim, por favor, não se preocupe que os desenvolvedores que trabalham no framework do Flutter serão distraídos por discussões sobre bugs. :-) Nós lemos as discussões e nos preocupamos muito com as opiniões de todos, mas no final do dia temos princípios orientadores claros e não vamos apenas reagir às vozes mais altas. Realizamos uma análise cuidadosa do mercado para determinar com o que a comunidade como um todo se preocupa.

Conversa interessante que me deixa com uma pergunta simples. Como a equipe do Flutter recomenda que passemos da fase de design (SVG) para gráficos vetoriais no Flutter?

@lukepighetti você pode tentar https://github.com/dnfield/flutter_svg e verificar o quão longe você leva.

Pessoalmente, não estou satisfeito com a solução oferecida para arquivos SVG no Flutter. Eu usei o pacote flutter_svg e não estou feliz com isso.

O suporte SVG precisa ser suportado nativamente na minha opinião na biblioteca padrão. Se vamos começar a usar o Flutter em telas maiores, como aplicativos de desktop e sites, isso é obrigatório.

@socialmammoth você pode explicar quais deficiências você está vendo?

Uma coisa que venho pensando há algum tempo é se valeria a pena suportar o formato .skp (SKIAPICT). Eu acho que há boas razões para não fazer isso diretamente - o formato não é garantido para ser estável de versão para versão do Skia sendo o grande.

No entanto, ele tem algumas propriedades interessantes - em particular, é possível fazer com que o Chrome/Chromium gere um SKP (talvez um SVG renderizado), e é muito provável que já suportemos a maioria ou todos os comandos de desenho Skia necessários para realmente renderizar a grande maioria dos SKPs.

Estou planejando criar um tipo de solução de geração de código para o plug-in SVG, para que você possa gerar código Dart/Flutter a partir de um SVG. Acho que neste ponto provavelmente seria mais interessante investigar um processo de compilação SKP para Dart - parte do código escrito para Flutter SVG poderia ser portado para a estrutura (por exemplo RawPicture e infraestrutura relacionada, que corresponde aproximadamente a RawImage ), e poderíamos conectar algo que levaria a saída de um SKP (talvez gerado a partir de um SVG como renderizado pelo Chrome, que é praticamente o padrão-ouro para renderização de SVG de qualquer maneira). Deve ser possível fazer ferramentas que levariam um SVG, invocar o Chromium sem cabeça para renderizá-lo em um SKP e, em seguida, transformar o SKP em alguns arquivos Dart que o Flutter poderia renderizar em tempo de execução.

Uma grande área que isso não resolve é carregar dinamicamente um gráfico vetorial em tempo de execução (por exemplo SvgPicture.network ), mas estou interessado em saber se isso ainda seria uma solução válida/aceitável mesmo com essa limitação.

Também digo isso com a crença de que, neste momento, nunca teremos suporte "nativo" para SVG no Flutter. Isso ocorre em parte porque o próprio SVG tem muita bagagem (XML, CSS, capacidade de buscar ativos externos) que não são triviais de implementar fora de um software de renderização de navegador/HTML e adicionariam muito inchaço ao software que estamos tentando para se inclinar. Também é em parte porque é inteiramente possível implementar um pouco de SVG sem fazer grandes mudanças na estrutura - embora algumas coisas ( filterEffect s e textPath s em particular agora) provavelmente beneficiar de mais alguns ajustes no motor.

Acho que poder carregar SVGs diretamente da rede é um grande benefício, mesmo que isso signifique que suportamos apenas um subconjunto da funcionalidade do formato.

Ter um formato vetorial específico para Flutter soa como o que o Android está fazendo com VectorDrawables, que embora funcione bem, também significa que não pode se beneficiar de muitas das ferramentas que já existem para SVG. Também torna difícil iterar designs por causa de todas as conversões de formato.

Eu gostaria de ver o Flutter suportando SVGs nativamente porque é isso que os desenvolvedores de front-end esperam de seus frameworks em 2018. Eu gostaria que os desenvolvedores de front-end achassem o Flutter acessível, porque eu quero que o ecossistema cresça.

@dnfield

Formato .skp (SKIAPICT).

IMHO abordagem interessante. Mas as ferramentas Flutter (pelo menos no AS) precisam lidar perfeitamente com a conversão. Os designers estão um pouco acostumados com as restrições impostas pelas importações vetoriais atuais do Android, então eles certamente serão capazes de lidar com outros conjuntos de prós e contras.

Para o desenvolvedor casual, o manual deve ler: " Solte seus desenhos svg aqui, anote aqui, use à vontade flutter analyze você o que está errado no seu svg ". Ou algo assim.

@dnfield

obtenha o Chrome/Chromium para gerar

Bom para PoC e testes, mas a solução real IMHO pode não exigir uma dependência tão grande - e uma que é difícil de script como etapa intermediária de CI. Claro que na versão beta e depois como uma segunda 'maneira difícil' pode ser ok - por exemplo. para obter desenhos animados fáceis que o skPicture permite. Posso estar errado. como designers geralmente têm um grande balde com navegadores sob a aba do laptop. No entanto, lembre-se de que as obras de arte mudam com frequência. Não apenas na fase de prototipagem, mas também à medida que o tempo de lançamento se aproxima e os desenvolvedores estão na febre da caça aos bugs.

[Ou seja. Precisamos de ferramentas de vibração para lidar com a importação de svg em conformidade ou precisamos de uma maneira em que o cromo esteja inteiramente nas mãos do designer. Não do desenvolvedor.]

PS. A maneira do pacote launcher_icons pode fazer no início: flutter packages pub run flutter_svg_to_skp:main -i path/to/svgs -o path/to/skps .

-- meu ¢2

@cachapa

ser capaz de carregar SVGs diretamente da rede

Este é um trabalho para um pacote enorme separado que lidará com validação e soluções alternativas
em torno de possíveis incompatibilidades e manias do produtor.
Primeiro, faça com que o mecanismo desenhe o formato vetorial fornecido pelo desenvolvedor que o pacote "Carregar SVG da rede" certamente usará. :)

Só para ficar claro @cachapa e @ohir - flutter_svg _already_ suporta carregar um SVG pela rede ( SvgPicture.network ). No entanto, esse pacote nunca acabará suportando a totalidade da especificação SVG - o objetivo é realmente apenas suportar o suficiente da especificação para renderizar a maioria dos SVGs. Ele já faz isso, com as principais exceções neste momento sendo fliterEffect s (portanto, sem borrões, filtros de cores, etc.) e muito suporte relacionado a texto - mas existem alguns outros ( marker s não são suportados, certos tipos de referências xlink:href ainda não são suportados). Há também alguns problemas que não estou dando suporte intencionalmente, como a especificação CSS completa, scripts e interatividade.

@lukepighetti Acho que essa expectativa realmente só existe com desenvolvedores front-end baseados na web. Qt suporta SVG, mas apenas um subconjunto limitado. O GNOME suporta um pouco mais com librsvg, mas novamente isso tem alguns problemas (e é realmente difícil de usar fora dos ambientes Linux). Estou animado para ver o que acontece com o resvg, mas não conheço nenhuma biblioteca de GUI que o integre.

@dnfield Não quero criticar seu trabalho, pois você fez um ótimo trabalho e agradeço imensamente por isso. Estou apenas decepcionado que a cor não funciona como esperado. Eu tive que escolher minha própria cor, não sou artista, também sou daltônico.

O Flutter precisa suportar SVGs da mesma forma que os navegadores modernos. É uma obrigação. Precisamos ser capazes de usar ativos copiados ou importados diretamente de uma página da web sem modificação.

Francamente, graças a Deus, pelo menos há um pacote, mas precisamos de cores, precisamos de efeitos, se o desempenho é um problema, torne opcional para as pessoas desativar os recursos e não forçá-los a ativar os recursos.

Precisamos de suporte completo de especificações para SVGs. Concordo com @lukepighetti . Com o Hummingbird, isso é obrigatório, ou os desenvolvedores da web rirão do Flutter e darão um passe duro.

Até @yjbanov menciona isso em seu artigo aqui: https://medium.com/flutter-io/hummingbird-building-flutter-for-the-web-e687c2a023a8

Como @dnfield mencionou 'resvg', @SocialMammoth talvez flutter_svg também deva buscar suporte 'SVG estático' em vez de suporte svg completo:
http://www.w3.org/TR/SVG11/feature#SVG -static,
que eu acho que deveria deixar todo mundo feliz.

Mesmo o Chrome não suporta todos os recursos SVG e, especialmente, a renderização de texto da direita para a esquerda é problemática (sem nenhum progresso nos últimos anos). Em outras palavras, não acho que o suporte completo a SVG seja realista. SVG-static parece ser um subconjunto razoável. Em flutter_svg sinto falta de text hadling (incl. texto no caminho), filtros e máscaras. Seria bom ter suporte no Flutter para construir algo assim https://drifted.in/horologium-app/

@SocialMammoth

O Flutter precisa suportar SVGs da mesma forma que os navegadores modernos fazem

Não. Os aplicativos Flutter precisam ser enxutos. Este problema não é sobre o pacote todo-poderoso para lidar com todo o SVG, ele diz explicitamente "suporta um formato de desenho vetorial" (não suporta SVG ). O objetivo, pelo que entendi, até agora é livrar todos os aplicativos de vibração de ativos de bitmap o máximo possível. E isso no nível do motor. @dnfield fez um ótimo trabalho por meio de um pacote. Agora é hora de apenas obter alguns gráficos vetoriais disponíveis no Dart sem aumentar o mecanismo de vibração (skia) ou o próprio aplicativo . O uso de .skp parece uma boa escolha para esse objetivo. Ele já permite mais do que o desenho vetorial do Android e já está no mecanismo. Os designers se acomodarão ao seu conjunto de recursos.

@ohir Acho que discordamos então. Um framework front-end que não suporta arquivos SVG é realmente uma piada de mau gosto.

Bem, eu não acho que o flutter PRECISA de svg para ser útil, mas seria bom. E se não for svg, então algum formato que seja fácil de obter de seu aplicativo típico de gráficos vetoriais.

Basicamente, SVG é o formato vetorial padrão a ser usado aqui, mas não podemos esperar suporte para todos os recursos do SVG. O objetivo sempre foi oferecer suporte mínimo para importar ativos vetoriais de aplicativos gráficos vetoriais típicos. Quais aplicativos gráficos vetoriais podem ler e gravar .skp ?

Meu teste para saber se um formato vetorial é onipresente o suficiente é se ele está disponível no Adobe Illustrator, Affinity Designer e Inkscape. Tanto quanto eu sei que praticamente deixa SVG. E concordo que não precisamos de todos os recursos SVG. Apenas traçados e preenchimentos de caminhos básicos estão bem.

Não posso dizer isso com autoridade, mas suspeito que seria mais fácil implementar um subconjunto de SVG do que convencer aplicativos de gráficos vetoriais a suportar .skp ?

@lukepighetti : A ideia do Dan é usar o formato interno do motor. O cerne desta solução é converter o SVG para o formato que o mecanismo entende. Não importa se o Inkscape conhece esse formato, desde que exista algum conversor viável.

Eu estava em dúvida ontem, mas hoje, depois de um pouco de pesquisa, parece-me que a automação do chrome é bem suportada. Se o cromo sem cabeça pode ser usado com um proxy de renderização , ele também pode ser um conversor svg->skp . Um pouco pesado, mas acessível. Frutas de baixo custo, @dnfield :).

Tudo se encaixa muito bem com as metas estabelecidas por @Hixie há quase três anos.

@dnfield por favor me corrija se eu estiver errado.
Estou assumindo que .skp é basicamente o formato binário para um Skia Picture.

Dado que o dart:ui também tem um wrapper para Skia Picture que pode ser gerado a partir da terra do Dart, o conteúdo dessas imagens não conterá recursos Skia diferentes? Basicamente, o do Chrome usará todas as funcionalidades do Skia, enquanto o do dart:ui não (limitado pelo que foi disponibilizado via mecanismo Flutter)? Meio estranho para o argumento de 'desempenho', não é? Flutter engine & dart:ui remove todo o Skia que foi considerado lento (sem mostrar números de desempenho), mas você pode usar tudo isso se vier através do arquivo .skp gerado pelo Chrome?

Outra coisa, ao usar .skp como você especificaria as cores de um ícone, se por exemplo o ícone usa 2 cores ou mais?

Que tal o velho argumento de que usando Dart no Flutter você tem controle sobre cada pixel? Para mim, o pacote flutter_svg que suporta 'svg static' é o caminho a seguir, pois permitirá inovações futuras na terra do Dart. Ao ignorar o Dart e apenas deixar o C++ lidar com isso, parece que o Dart não conseguiu hackeá-lo.

Skia parece suportar SVG. Por que o Flutter não fornece suporte SVG diretamente?

Pelo que posso dizer, a equipe do Flutter quer manter o tamanho do pacote Skia o menor possível. Eu não sabia que o Skia suporta SVG, mas se isso acontecer, isso é um fruto fácil. Como nota, há outro problema em adicionar suporte ao Lottie para Flutter porque o Skia o suporta.

Skia não suporta a importação de desenhos de SVG, mas tem algum suporte experimental para criar SVGs (o que não é tão útil aqui).

E sim, o tamanho do pacote é uma preocupação.

Por favor, se você quiser solicitar suporte SVG, consulte: https://github.com/flutter/flutter/issues/15501

Este bug é especificamente sobre o suporte a gráficos vetoriais sem suporte a SVG.

Para pessoas que são interessantes em um formato de gráficos vetoriais, estou curioso sobre seus casos de uso.

Estou ciente destes até agora:

• Ícones. Imagens estáticas que podem precisar ser recoloridas dinamicamente (por exemplo, esmaecidas quando desativadas) e podem precisar ter níveis variados de detalhes dependendo do tamanho de renderização de destino. É improvável que tenha texto.

• Ícones animados: Dois ícones, conforme descrito acima, e uma descrição de como fazer a transição perfeita de um para outro.

• Cenários: Imagens que podem ser muito maiores que a tela, talvez mostradas com paralaxe; geralmente cenas simples com formas, gradientes e sombras, improváveis ​​de ter texto.

Existem outros casos de uso que motivam sua necessidade de gráficos vetoriais? Por favor, descreva-os aqui. Obrigado.

Suporte a várias resoluções com um único gráfico, principalmente com compatibilidade avançada para telas de resolução mais alta

Meu aplicativo é basicamente um companheiro para uma conferência. Quero incluir mapas do hotel, com possibilidade de panorâmica e zoom. Usar um raster de alta resolução é impraticável por motivos de tamanho e desempenho; gráficos vetoriais são perfeitos.

No momento, estou usando uma visualização da Web em PDF incorporada, que é super inconveniente e só funciona online (embora eu provavelmente pudesse contornar isso se precisasse).

• Botões personalizados 'semelhantes ao real' são praticamente inatingíveis sem gráficos vetoriais. Especialmente aqueles que giram, inclinam ou derretem .

Para acrescentar ao que Dan disse: apenas 1kB de fonte vetorial pode produzir detalhes finos e imagens suaves tanto em tablets de 7" quanto em TVs 4HD de 105". Caso recente do aplicativo Quiosque de caixa registradora para telas de 10 ou 14" (voltado para o caixa) e 5 ou 7" (voltado para o cliente). O conjunto de mais de 5.000 desenhos vetoriais de guloseimas tinha menos de 5 MB de tamanho. Apenas o subconjunto de 'vegetais' (~ 150) convertido em pngs para exatamente duas telas usadas foi superior a 30 MB. O conjunto de inventário completo pode terminar no intervalo de GBytes.

PS A próxima grande coisa seria ter gráficos vetoriais com regiões de toque definidas, por exemplo, por meio de um preenchimento escolhido. Isso teria poupado milhares de linhas de código para toda a classe de interfaces principalmente estáticas, mas ricas em detalhes.
Como nos Manuais do Operador de Máquinas interativos.

Sonhos à parte - deixe nossos designers usarem desenhos vetoriais simples primeiro :)

Obrigado pelo feedback até agora. Muito útil.

@ohir Você pode elaborar sobre "girar, inclinar ou derreter"?

Minha solução para isso que estou realmente muito feliz é usar o pacote path_parsing (https://pub.dev/packages/path_parsing) para gerar comandos de desenho de tela a partir de uma string de caminho SVG e, em seguida, usá-los para fazer um widget CustomPainter que o desenhe. Para outras formas SVG além de caminhos (retrato, círculo, etc.) eu apenas as traduzo manualmente em comandos de desenho, o que é um pouco tedioso, mas não muito difícil.

Isso funciona muito bem para ícones vetoriais simples e permite que você use o mesmo widget com tamanhos e cores diferentes em todo o aplicativo.

Aqui está o código: https://gist.github.com/jpotterm/7b30739e0af722baf97a397d9841d908

Poderia ser realmente útil se houvesse uma ferramenta oficial de linha de comando flutter que analisasse um arquivo SVG e produzisse comandos de desenho de tela que produzissem um resultado semelhante.

@Hixie
Por exemplo. https://dribbble.com/shots/1083175-Air-condicionado-controller#
O botão giratório central e o medidor ao redor dele podem ser meticulosamente desenhados com a API Canvas atual, mas também podem caber em 2Kb (xml svg) e cerca de 300-500B de drawable. Se gráficos vetoriais e transformações afins rudimentares do nível Skia fossem expostas por meio de alguma interface de 'gráficos vetoriais', esse botão poderia ser ativado apenas com a aplicação de preenchimentos nos segmentos do medidor e girando um caminho do pequeno círculo indicador.

O mais importante é que todo esse puxador, com cores e outros detalhes, seria desenhado exatamente como a designer planejou - pois seria todo o trabalho dela apenas embutido. Interface de desenhos vetoriais + preenchimento + gradientes + bom designer pode se parecer com: https://www.artua.com/app-design-deckadance/
Transformações afins por parte do desenvolvedor tornarão esse design responsivo e vibrante.
Quanto às transformações de inclinação e cisalhamento: pode, por exemplo. ser usado para modelar uma alavanca de controle de mudanças.
(Mudança de palavras "derretida" provavelmente induzida pelo fantasma de Salvadore Dali;)

/fora do assunto/

@jpotterm
Poderia ser realmente útil se houvesse uma ferramenta oficial de linha de comando flutter que analisasse um arquivo SVG e produzisse comandos de desenho de tela que produzissem um resultado semelhante.

Eu produzi algo semelhante. Gerador de código que procura uma anotação e pega o SVG PathData especificado e gera um getter que retorna um objeto Path. Se as pessoas quiserem, eu poderia limpá-lo e abrir o código.

O aplicativo para o qual contribuo é perfeitamente adequado para gráficos vetoriais. Ele tem centenas de pequenos gráficos de arte de linha em preto e branco que constroem a interface do usuário. Estes podem ser tingidos e redimensionados.

Fazer isso em várias cores em todas as densidades diferentes seria horrível, insustentável e tornaria o pacote final gigante. Essas imagens vêm de gráficos desenhados à mão.

Obrigado a todos por seus comentários. Comentários muito úteis.

Para pessoas que são interessantes em um formato de gráficos vetoriais, estou curioso sobre seus casos de uso.

Outro caso de uso é basicamente qualquer coisa que precise de gráficos dinâmicos:

• gráficos
• barras de carregamento
• desenhando
• etc

Na verdade, estou muito surpreso que o Flutter não suporte isso, já que o Skia tem suporte para um subconjunto de SVG (as partes úteis de qualquer maneira).

Eu gostaria de usar SVGs para arte. Um PNG de tablet de tela cheia de qualidade pode ter 2 MB ou mais, enquanto o SVG equivalente pode ter de 5 a 10 KB. Adicione algumas telas e estamos falando de 20mb ao pacote em vez de 100kb.

Para gráficos programáticos eu sou um grande fã de CustomPaint, então eu nunca usaria SVG para coisas como gráficos, barras de carregamento, desenho, etc. E sim, embora eu concorde que é caro escrever coisas no CustomPaint, o que você obtém no final é sólido e renderiza muito rápido e muito bem.

Se você for oferecer suporte a SVG, precisará oferecer suporte a todos os recursos SVG, como gradientes, traços e muito mais. Isso não foi feito no projeto Android e isso levanta alguns alertas para os desenvolvedores, já que quase todos os outros dev. plataformas suportam SVG e vetores. É o básico dos gráficos, faça certo!

@harounhajem , consulte https://github.com/flutter/flutter/issues/15501 para esse tópico, bem como https://github.com/dnfield/flutter_svg

@PierBover para gráficos especificamente, considere https://pub.dev/packages/charts_flutter

Acabei de entrar no Flutter. Eu estava refatorando um aplicativo pessoal do Ionic 3 para o Ionic 4 e era (novamente) totalmente diferente e exigia um aplicativo do zero.
Então decidi mudar para o Flutter e tentar. Como eu disse, eu tinha este aplicativo finalizado e funcionando e isso inclui muitos gráficos e ícones que eu tinha prontos no meu aplicativo. Não sou designer e preciso pagar por esses designs.
Entendo que não sou o único nesta situação, querendo reutilizar seus ativos SVG.

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

(não tenho certeza porque não está fechado então)

Porque o problema real - suporte a um formato de desenho vetorial diferente de SVG - não foi resolvido?

ah, minha culpa @jonahgreenthal. Eu vim aqui procurando suporte SVG e vi que o terceiro comentário estava pedindo a mesma coisa

Uber fez isso para iOS: https://github.com/uber/cyborg
Seria interessante ver algo assim no Flutter.

Alguma atualização sobre isso?

@dnfield que funcionou bem exibindo um svg como novo widget, mas não funciona com a propriedade AssetImage . Eu preciso exibi-lo usando um widget CircleAvatar

@Hixie também há um caso de uso em que o ícone svg precisa ter várias cores, pois ajuda o usuário a entender o significado do ícone. Portanto, espero que a solução inclua a capacidade de personalizar a cor do tema também.

Atualmente, algumas pessoas sugerem converter SVG em fonte e usá-lo da mesma forma que o pacote de ícones, mas não podemos ter várias cores no ícone neste caso.

4 anos de vários comentários sem nenhuma solução útil. Em suma - não, não, possível. Não, não planejado.

Podemos pelo menos saber por que isso é tão problemático/difícil?

Flutter_svg tem suporte decente para SVG em flutter. O Rive também suporta um formato baseado em vetor para vibração.

Esta edição trata da criação de um novo formato baseado em vetor. Isso leva tempo :)

@dnfield existem alguns widgets com propriedades de fundo que não podemos passar svgs. Existe alguma maneira de arquivar isso?

por favor, adicione suporte svg adequado em vez de criar um novo formato. Svg é o padrão de fato.

Sempre que crio um aplicativo, geralmente há um site associado, e os sites usam svg e svgs lindamente animados, que são leves e bonitos em qualquer resolução.
Realmente faria sentido apenas reutilizar esses svgs animados no Flutter para que a consistência possa ser alcançada adequadamente em vez de ter imagens e animações reimplementadas!

O SVG já existe, funciona e está amplamente disponível, usado e suportado em todos os outros lugares. Foco nisso é o que precisamos.

Esta edição é sobre a criação de um novo formato baseado em vetor

Então você quer dizer que essa questão é sobre reinventar a roda, certo? Eu concordo com @d-silveira - melhor adicionar suporte adequado para svg, não precisamos de nenhum novo formato baseado em vetor.

Sim, trata-se de inventar uma roda melhor. O SVG já é suportado no Flutter usando flutter_svg.

Melhor poder importar svg e processá-los internamente, seja em tempo de compilação ou gerar código automaticamente durante a importação. Semelhante ao Android nativo - você pode importar svg e o xml de definição de caminho do Android será gerado a partir do svg de origem. Importar para o projeto Flutter pode gerar código de dardo a ser reutilizado para desenhar ativos vetoriais.

@Hixie é bom para melhorar as coisas, não vou discutir isso, mas como podemos oferecer suporte a alguns widgets que permitem apenas imagens não svg nesse meio tempo? (por exemplo, aqueles com propriedades de fundo)

Isso seria uma solicitação de recurso para flutter_svg.

O @Hixie Flutter SVG poderia criar uma imagem lá, mas seria bom se a estrutura fosse mais tolerante a tirar fotos do que imagens em alguns casos. Arquivado https://github.com/flutter/flutter/issues/49712

flutter_svg

Por que é que? Isso não está relacionado com o pacote flutter_svg :

CircleAvatar(
  backgroundImage: MySVGImage(),
)

@Hixie flutter_svg só funcionará para alguns dos casos. Deixe-me dar um exemplo prático: eu preciso consumir uma API REST que em alguns de seus endpoints retorna urls de imagens. As imagens são geradas pelo usuário em um backoffice, portanto, algumas são png, algumas são jpg e algumas são svg. O backoffice não inclui a extensão do arquivo na url e não suporta HEAD, então não temos como saber o tipo de imagem com antecedência.
O comportamento esperado do flutter seria receber a url em image.network e manipulá-la, em vez de me forçar a pular por aros para adivinhar que tipo de imagem é, e se for svg mudar para flutter_svg.
Tudo isso nem leva em conta o fato de que o flutter_svg não é um substituto imediato para a imagem em todos os casos! :p

O SVG em geral só funcionará para alguns casos de uso também. :-)

Este problema específico é sobre ter um formato de gráficos vetoriais não SVG. Se você tiver um requisito diferente, recomendo arquivá-lo como um problema separado.

Da discussão anterior, algumas considerações importantes são:

• Não queremos suporte total a SVG. Há muito na especificação que é caro, pesado e/ou duplica o que já temos no Flutter.
• Devemos enfatizar em nosso formato suportado que as operações são eficazes/eficientes/otimizadas em nosso mecanismo gráfico (Skia).
• Podemos querer processar o formato em tempo de compilação em vez de oferecer suporte a um interpretador de tempo de execução completo.

Então, como alguém cria um novo formato vetorial para imagens otimizadas para vibração? Com base no acima, acho que é o que está sendo sugerido ...

Talvez os caras do Rive possam montar alguma biblioteca de conversão de SVG. Eles já têm um mecanismo vetorial proprietário (e de código aberto) para o Flutter. @luigi-rosso

Por que não adicionar suporte à importação de svg no projeto Flutter. E converta para código de dardo/novo desenho vetorial etc. Observe que a mesma situação está no Android nativo, é por isso que não usamos svg diretamente (o que concordo não faz muito sentido) e importamos para o projeto, svg é retirado funcionalidades não suportadas e não necessárias e convertidas em definição de caminho android.

Não é uma boa ideia para o Flutter?

@giaur500 Este problema não é sobre isso. Se você tiver uma sugestão especificamente sobre SVG, registre um problema separado.

Para ser justo, muitos dos comentários nesta edição estão discutindo SVG e Flutter.

Segue

O SVG é perfeito para uma ótima interface de usuário em nível de pixel. Corretamente o melhor até agora para ótimos pixels.

@lukepighetti Sim. Infelizmente, eles são todos fora do tópico e tê-los aqui não resultará em nenhuma melhoria no Flutter.

Da discussão anterior, algumas considerações importantes são:

• Não queremos suporte total a SVG. Há muito na especificação que é caro, pesado e/ou duplica o que já temos no Flutter.
• Devemos enfatizar em nosso formato suportado que as operações são eficazes/eficientes/otimizadas em nosso mecanismo gráfico (Skia).
• Podemos querer processar o formato em tempo de compilação em vez de oferecer suporte a um interpretador de tempo de execução completo.

Uma ferramenta de tempo de construção seria ótima, pegue o vetor e renderize todas as densidades de tela e adicione os ativos como imagens. Apples iOS faz isso com ícones PDF.

Melhor poder importar svg e processá-los internamente, seja em tempo de compilação ou gerar código automaticamente durante a importação. Semelhante ao Android nativo - você pode importar svg e o xml de definição de caminho do Android será gerado a partir do svg de origem. Importar para o projeto Flutter pode gerar código de dardo a ser reutilizado para desenhar ativos vetoriais.

eu gosto disso

@giaur500 Este problema não é sobre isso. Se você tiver uma sugestão especificamente sobre SVG, registre um problema separado.

Nova edição foi criada: https://github.com/flutter/flutter/issues/63752

Então, qual é o estado disso?
Existe alguma intenção de suportar algo semelhante ao VectorDrawable, ou mesmo o próprio VectorDrawable para aqueles no Android?

Como desenvolvedor pensando em adotar o ecossistema, eu diria que esse é um ponto forte que me convenceria a permanecer nativo.

Eu nunca tentei, mas o flutter svg lib costumava ter suporte para at
menos recursos-chave de vetores desenháveis ​​como caminhos.

No sábado, 15 de agosto de 2020, 19:46 n00bmind, [email protected] escreveu:

Então, qual é o estado disso?
Existe alguma intenção de apoiar algo semelhante a
VectorDrawable, ou mesmo o próprio VectorDrawable para quem está no Android?

Como desenvolvedor pensando em adotar o ecossistema, eu diria que esta é uma
ponto forte que me convenceria a permanecer nativo..

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/flutter/flutter/issues/1831#issuecomment-674375846 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/ABI4Y4LWYSYEIWI3RRSSCK3SAZKO5ANCNFSM4B3FXMMQ
.

Acho que o estado não é nada. Nenhuma conclusão existe aqui a partir deste tópico e também minha ideia de desenvolver algo semelhante ao desenhável de vetor nativo fechado imediatamente.

Existe alguma razão pela qual o pacote flutter svg não funcionará para você? Estamos usando-o com grande sucesso em um de nossos aplicativos. Eu nunca usei o Vector Drawable, então não tenho certeza de como ele se compara ao SVG.

Parece que vale a pena dar uma olhada no pacote flutter_svg para esse tipo de caso de uso.
@lukepighetti como você classificaria seu desempenho? Meu uso seria apenas uma imagem inicial e alguns gráficos do tamanho de ícones aqui e ali no aplicativo, então nada extravagante.

Parece que vale a pena dar uma olhada no pacote flutter_svg para esse tipo de caso de uso.

@lukepighetti como você classificaria seu desempenho? Meu uso seria apenas uma imagem inicial e alguns gráficos do tamanho de ícones aqui e ali no aplicativo, então nada extravagante.

Eu classificaria muito alto para o seu caso de uso. Acho que as pessoas deveriam realmente tentar antes de pressionar a equipe de flutter a fazer algo internamente.

@lukepighetti

antes de pressionar a equipe do flutter para fazer algo internamente.

O problema real com esse problema em particular é que o Skia, o mecanismo gráfico de vibração, tem tudo o que é necessário para fazer o formato vetorial "desenhável" rodando na velocidade mais alta sem importar um pacote dart bastante pesado que chama o mecanismo para desenhar primitivos passo a passo.

Eu acho que as pessoas realmente deveriam tentar _(pacote svg)_

Acho que as pessoas deveriam chamar em voz alta e em todos os lugares possíveis os Googlers para essa questão do gh, porque agora - depois de quatro anos - apenas relações públicas negativas podem chutar alguém no Google para pensar se a estrutura móvel no ano de 2020 deve realmente nos forçar a levar todos aqueles megabytes de gráficos raster em nossos aplicativos.

[@Hixie]

A menos que esteja faltando alguma coisa, a implementação de tal recurso de vibração seria muito parecida com o pacote flutter_svg de @dnfield que parece resolver o caso de uso que você está descrevendo. Além disso, o mantenedor está na equipe principal do Flutter para que possamos ter certeza de sua qualidade. Você se sentiria melhor se este pacote estivesse em https://github.com/flutter/plugins ?

Se houver algo que eu esteja perdendo, sinta-se à vontade para me educar para que eu possa aprender mais sobre esse tópico.

@lukepighetti

Eu acho que "não SVG" no título da edição deveria estar em vermelho, em negrito e piscando.

Este problema não é especificamente sobre o formato svg.

OP (e eu) tinha esperança de expor a API de caminho de Skia para que os gráficos de ativos pudessem ser representados em uma forma compacta - ou seja, binário de endianess fixo. Dan até fez um patch para Skia que funciona para o flutter_svg, que por sua vez agora nos permite usar ativos svg. Embora ainda analisemos xml no tempo de execução do aplicativo e desenhe chamando o mecanismo - também para os ativos estáticos agrupados no apk.

Com suporte adequado para o formato de desenho vetorial personalizado (vamos chamá-lo de fvd ), a análise do trabalho do designer aconteceria uma vez - no momento da compilação do aplicativo, o objeto no formato fvd seria lançado diretamente no Skia. Em aplicativos com muitos gráficos, essa abordagem teria um efeito enorme no tamanho do aplicativo e uma economia notável no tempo de renderização. [ citando a si mesmo ]

Espero que acima mostre como vejo esse problema e justifique meu apelo para que ele finalmente seja feito.
Mesmo como parte da biblioteca flutter_svg.

Flutter merece ter mais uma vantagem sobre as tecnologias concorrentes.

Por que vale a pena, não há nada inerentemente errado em usar flutter_svg, é apenas que está faltando algumas coisas muito simples, por exemplo , não suporta porcentagens e travamentos diretos ao tentar renderizá-los. Este comentário não é um golpe na biblioteca flutter_svg, é apenas para explicar às pessoas que estão dizendo que podemos usar flutter_svg.

flutter_svg parece funcionar muito bem, apesar de não suportar scripts, HTML, SMIL etc.

parece bom e podemos construir SVG a partir de arquivos, rede ou strings comuns.