Other random thoughts (not all mine):

• We really want to avoid supporting a format where there's a preexisting expectation of implementing features that are not going to be performant. For example, implementing SVG will lead people to expect full SVG support including scripting, HTML, SMIL, etc.
• We should design our format explicitly very closely aligned to performance features in Skia, e.g. drawAtlas.

Vector support seems crucial for an app framework that supports various screen sizes and densities. Otherwise you end up with icons that look like this:

Instead of this:

@HansMuller

Kris mentioned this as well: we could do some limited SVG processing at build time. For example we might generate MD icon Widgets based on the SVG descriptions. If done carefully that might save space and increase fidelity to the original designs.

For material design icons specifically, we should investigate using the material design icon font.

@appsforartists For what it's worth, neither Cocoa nor android.view use vector formats for icons.

@abarth Doesn't surprise me about iOS - seems like they started with a hardcoded 3.5" screen and have tried pretty hard to keep that mental model/simplicity of supported resolutions ever since (see: the width of each iPhone being the same, or the original iPad and iPad mini having the same resolution). I don't know much about mobile development, but that's slightly surprising about Android not being vector-based.

In any case, the icons should not look aliased like they do in the above screenshot, and vectors are a nice solution for resolution independence. How you guys choose to implement to solve for pretty icons is up to you. :smiley:

How you guys choose to implement to solve for pretty icons is up to you.

Would you be willing to file a separate issue about the resolution issue you were seeing with icons? @krisgiesing implemented a resolution-aware asset resolver that handles many cases. It would be valuable to learn about the cases that it doesn't handle.

I'm looking at adding some tests for the current resolution awareness support, so now would be a great time to understand if something's not working right.

It looks like the 3x has a device pixel ratio of 2.6, which we probably don't have an asset for.

I'm looking at this specific case now. The device pixel ratio is 2.625; we're choosing the 3.0x asset, which is expected. However, something seems to be going on during the rendering that is causing some kind of extra aliasing artifacts. So although @abarth fixed the case of the Material Design icons by switching to a font, I'm still investigating on behalf of other types of image assets that need resolution dependent scaling.

I'll open another bug to track this since it's is tangential to support of a vector format.

See #2337

Android supports the "VectorDrawable" format which is just a well-performing subset of SVG. I hope you consider using the same format, given that it already has some community support and the Android team has apparently deemed its performance adequate.

VectorDrawable is certainly influenced by SVG but it's not a subset. Also it uses XML, which pretty much guarantees that it's not going to be the most performant vector format one could come up with. :-)

It was wrong to describe VectorDrawable as a strict subset, but it still seems to be a balanced compromise between ensuring good _render_ performance and ease of use. The VectorDrawable specification frequently defers to the SVG specification for key areas like path data syntax, making it much easier to convert SVG assets that many developers already use and share VectorDrawables that existing Android apps already contain.

I can't imagine that XML is a significant performance blocker because it only affects parsing. It seems to me that _render_ performance - the kind of performance that affects Flutter's goal of 60fps apps - is more dependent on the set of vector operations that Skia will have to draw, not a parsing step that can be done once and cached.

I don't want to belabour the point but I can't help feeling that the work for this has already been done and therefore doesn't need to be shelved in the "after 2.0 release" milestone.

We ended up using the Material Design font for the Material Design Icons. I'm not aware of any obstacles stopping someone from building this on top of Flutter today using direct dart:ui calls or a CustomPaint widget: https://docs.flutter.io/flutter/widgets/CustomPaint-class.html. We have no immediate plans to build such at this time.

$.02 - even janky browsers (and competitor framework React Native never mind, their solution is hacky) can render SVG. The image export option requires creating a minimum of 3 files for each icon or art asset for my team. That's a poor practice compared to one SVG file can be displayed at any resolution.

For the above comment by Hixie, pre-existing expectations shouldn't inhibit implementing a worthwhile feature. I'd much rather be able to have basic support for SVG display (which solves many problems for me and my team) and find out extended options aren't available than rely on an ever-increasing number of PNGs to accommodate the ever-increasing number of screen resolutions.

I'm falling back to making a font for my team but that's not as good as native SVG support because the font format adds extra formatting for line-height and letter spacing that has to be adjusted in the app. Also, fonts want to be displayed at fixed resolutions (12px, 16px, 20px, 36px...) which is also limiting.

Thank you for cool Flutter framework. :)

I would encourage anyone who wants SVG support to implement SVG support as a Dart package for Flutter.

For those interested, I'd point to https://docs.flutter.io/flutter/dart-ui/dart-ui-library.html which is the low-level library for drawing.

From team: Dart library not good enough solution. Just passing it on.

Can you elaborate on that? The whole of Flutter's framework is a Dart library; anything we implement here will likely be a Dart library. What are the requirements for "good enough"?

Case in point, I implemented a (simple, non-exhaustive) SVG parser in pure-Dart a while back:

https://github.com/matanlurey/svg

It would likely be somewhat trivial to either:

a. Create a runtime SVG -> SvgRenderElement, which uses dart:ui under-the-hood.
b. Create a build-time compile step that converts an SVG into something like:

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

@deborah-ufw if you're interested, we'd love to chat to learn more. Can you email me?

Hi Seth, matanlurey and Hixie - thank you very much for the response. I'm probably not the right person to talk to in depth, since it was our lead engineers who rejected the Dart plugin solution (thus leading to generation of a huge library of png's for our app, which makes most of us cringe also).

I would like to pass the link for this Github issue on to them and ask them to contribute technical reasons for their comment (which was made rather more colorfully than I passed on) - I will do that just as soon as I finish typing.

They're also able to chat with our engineers directly via http://gitter.im/flutter/flutter as well as other contact methods listed https://flutter.io/support/ if needed. :)

I will add that in. Thank you! :D

Another approach is to integrate something like http://svgpp.org/ at the native level and use the Flutter plugin system to communicate with it. This would probably give you the best size/performance characteristics for full SVG support, but at the expense of maintaining a dependency.

What about looking for SVG support at the engine level? I don't think it's reasonable or desirable to expect full support of the standard, but part of the appeal is support for cross functional teams and existing tooling.

I got the impression Skia provides some basic SVG support. Is there no way to make this available to Flutter?

From what I can tell, it's only been experimental and partial. There's an issue open here https://bugs.chromium.org/p/skia/issues/detail?id=5596 bit it's over a year old. They're also listing it in their roadmap but again not clear what priority.

It wouldn't make sense to support SVG at the engine level because that wouldn't expose the SVG document model, which is a core part of SVG support.

If Flutter supports SVG, it's going to be with the eventual goal of actually truly supporting real SVG. It's against Flutter's philosophy to have half-hearted implementations of features.

I don't see exposing the SVG document model as a core part of SVG support. That'd be a nice to have but not a must have for the use cases that I have in mind.

Yes, library level support would enable more features - but if the engine itself was capable of rendering (a significant subset of) SVG data, that'd presumably be enough to allow rendering vector image assets defined by that subset of SVG.

This issue is clearly bigger than that, but I'd be happy to take existing SVG assets and render them properly at different resolutions without converting them all to bulky raster images.

Yeah, SVG asset file import would be really nice but the spec for SVG is over 800 pages long. Having said that to just import static files to render on Skia (which is a vector graphics library) shouldn't be a problem. So I am taking it on; as always I can only do work part time on weekends so you won't see stuff right away. Also I have a tonne of SVG files but they all use the same stuff (icon collections from flaticon) so I would appreciate sample SVG files from people that want this feature.

Carlos.

I've been noodling on this a bit over time as well. Here's what I've come up with:

Engine Level implementation

This seems attractive for the following reasons:

1. In theory supports something like image: new AssetImage('graphics/background.svg') to have some C/C++ code parse and translate the SVG data to Skia rendering commands
2. At least one good candidate out there that should be able to plug into Skia fairly easily (https://github.com/svgpp/svgpp) at the engine level
3. WebKit's SVG logic would be awesome but seems to have far too many dependencies
4. I don't think librsvg would port too well (tightly coupled to Cairo, transitioning to Rust as a primary language - would need to work out way to get to Skia as a backend at the least)

But it has at least a few difficulties:

• Properly handling text
• Properly handling CSS (if at all? but adding it is no simple task)
• Extending support for additional features (or allowing users to more gracefully add support for features) is challenging.
• Seems like it's be very difficult to handle animations

Dart level implementation

1. Flutter's dart:ui offers a lot of the primitives from Skia that SVG needs already
2. I suspect text rendering would be much more easily handled at this level than at the engine level
3. Should be easier for more of community to maintain/extend
4. Should be able to more cheaply handle direct interaction with the parsing logic (perhaps to handle exceptions and/or animations?)

But has a few difficulties:

• May not do much better supporting CSS
• May not do much better supporting animations
• Would likely be slower (but perhaps not by enough to matter, and could potentially be offset by AOT compiled SVG to Dart code)

Test data

As far as sample SVGs go, it'd probably be most useful to identify what SVGs are supported from the 1.1 test suite (or, if partially supported, what about them is partially supported). Those can be found here:
https://github.com/w3c/web-platform-tests/tree/master/svg/import

Or here with some PNG comparisons: https://www.w3.org/Graphics/SVG/Test/20110816/

@cbazza, which way are you thinking of implementing this? At this point, I'm leaning more towards a Dart package level implementation.

Also, I think icon type support is probably ly easily handled with something like IconData. It might be best to treat that separately, as it'd likely only have to support a single path per codepoint

I am thinking of 'Dart level implementation' on top of dart:ui.

2 basic use cases:

(1) load static icon svg files with something like your
"image: new AssetImage('graphics/background.svg')", where the
file could come from the file system or over the network
dynamically.

(2) Widget based svg support with DSX (JSX like construct)
which would look very similar to:
https://github.com/react-native-community/react-native-svg

Regarding 'Test data' I need real files from people that need
this and not the w3 test suite. SVG support would be dependent
upon what dart:ui supports so if a resired svg file contains
stuff that can't be done with dart:ui, I would be able to
find out fast.

Carlos.

I do not think we should go for the react native SVG model. I get wanting to support real life cases, bit I think covering the w3 suite would give us a better basline of what works and what doesn't and how challenging it would be to implement)

OK, there seems to be some misunderstanding...
When I do (1) it will take standard SVG files and I'll try to support as much as it can given dart:ui (Skia).
When I do (2), which is create widgets to handle SVG like constructs it will look very similar to that react-native-svg library. These are 2 very different things.

@cbazza the use case for svgs in our app is mainly for one-color svgs we use as icons. Here is a link to a zip file on Dropbox with a selection of recent svgs that are representative. https://www.dropbox.com/s/dp38wxc22625cvc/icons.zip?dl=0

Thanks for the interest in helping here, I would be happy to see an SVG Flutter plugin coming to life!

I wrote a tool that does some minimal parsing of a sequence of somewhat-SVG files and dumps out Dart files that we later use to show icon animations: vitool.

I used this tool to create the AnimatedIcons data, you can check the result by running the manual test app (cd dev/manual_tests; flutter run -t lib/animated_icons.dart).

It is far from being optimal or complete, but works for the current set of animated icons we have, and someone should feel empowered to fork/extend it.

@deborah-ufw for these single color icons something you can do is create an icons font, and show the icons using the Icon widget.

@amirh doesn't seem to be easy to create color vector fonts

@amirh if you read the whole thread above, creating and defining a font with glyphs as icons is an extra series of steps that has to be taken because SVG is not supported. SVG support is much more efficient than a font. Also, zoechi is right - any vector art that has several colors is nearly impossible to make into a font.

Sorry - I looked at the sample icons and thought that you only needed single color icons.

@deborah-ufw, thank you for the files, exactly what I was looking for and already found stuff that my files don't have.

@amirh, yes I have seen your great work already ;)

Do we finally have a straight way to source an svg or vector asset xml into the image for flutter

@Hixie: please (re)consider that for multi-platform native mobile teams this is a real pain point, but that only partial, relatively simple SVG support is needed to solve this. Towards the SVG standard maintainers this could be considered half-hearted, but Flutter is for mobile developers, not for general standards authors. Flutter would win the hearts of mobile developers if it alleviates their very real pain, even if only in a pragmatic manner.

Please also consider that despite this long-existing need, the community support approach has failed to produce workable solutions in Flutter competitor Xamarin (in my 5 years of Xamarin experience - libs can't handle design tool exports, are too limited, not stable, paid and/or closed source).

Because of this I am not optimistic that the Flutter community will succeed where the Xamarin community failed. I do estimate that a practical. partial support for SVG icons is something that the Flutter team could deliver, using existing Skia primitives.

This would fit the Flutter goal well: enable mobile developers to deliver beautiful, high performance UX in record time. It would improve productivity, fidility and performance (an SVG loads a lot faster than all those PNG's; icon SVG's typically have modest computational cost because a requirement for visual clarity quite often leads to a shape of modest complexity).

The core need is for a productive workflow from commonly used creative designer tools (such as Adobe) to scalable native app icons.

The current PNG approach is very wasteful in terms of productivity and app size; it is just so primitive to generate and ship every icon in up to 9 fixed bitmaps (6 Android, 3 iOS) that are then post-processed at runtime. The problem increases steadily as resolutions increase in size and variation.
It sticks out as a sore thumb in the otherwise delightful innovative and productive Flutter developer experience. I think Flutter has a real opportunity to win devs hearts & minds here,

Also @dnfield the above mentioned SVG features that are mentioned as obstacles for implementing in Flutter are in my experience either not relevant or are rare enough that falling back to PNGs for those design assets is a minor inconvenience.
Don't cares: CSS, HTML, SMIL, Document Model, scripting
Animation, Text: rare enough to fall back to other technologies for that

I hope the length of this comment conveys how much value a solution would have. Hth!

@VincentH-Net I am 100% with you because I feel the pain too !!! Please send me some of your SVG files. Perhaps Xamarin struggled to deliver SVG support due to lack of vector graphics engine that could handle it; this is not the case for Flutter with Skia so I am very optimistic that a community solution will happen.

FWIW, Xamarin also has Skia available in SkiaSharp. SVG can be tricky even for minimal implementation.

But @cbazza I'd be very interested in collaborating with you on this

And on the animation front, I think that enabling Lottie would satisfy a lot of use cases (and probably do it with better tooling for designers).

@dnfield I think these Lottie animations can easily be rebuilt as Flutter widgets

@dnfield, excellent you could be the low level guy handling changes in the engine level while I do the upper level work on widget (async svg parsing, 'picture' construction that can be cached and sent to canvas on rendering updates, etc).
yes, Lottie working would be great for designer/developer workflow.
@zoechi why rebuild something by hand with widgets when you can simply import a working Lottie widget that handles everything for you? Having said that my previous goal (2) above would work great with widget animations (hence why I want to do it too).

@zoechi - the goal would be to enable designers to create such things and render them with minimal effort on the developer's part. A secondary goal would be to enable loading them as resources at runtime, rather than necessitating precompilation.

The same is true for SVG - yes, a developer could certainly convert SVG vector data to Dart, but ideally you can just include a vector drawing (SVG or not) resource and render it at runtime.

In other words, I want to be able to tell my designer to create a vector asset once and be able to use it in my Flutter application with minimal modification (and without having the designer export it 5 times in various raster formats that will end up being invalid as soon as Apple or Samsung release their next phone).

various raster formats

yeah, that feels like the previous decade

https://github.com/luberda-molinet/FFImageLoading Might be worth looking at, uses Skia to render SVG for Xamarin

@escamoteur

Thanks, that looks really good, only thing missing is that it is not async ;)

I'm using only vector drawables in Android application recently, and I don't see any noticeable performance penalty. Icons are sharp and app size is a lot smaller. It's also much easier and faster to test different images. This @2, @3, @4, @5,.... solution looks like a huge step back in such a modern framework as Flutter is.
I don't understand why you just can't go to the team responsible for android vector drawables, and use their ideas or implementation (if possible) on solving that problem.

I've been toying around with some SVGs being drawn on a canvas here. path elements are probably the trickiest to implement, but there's a Skia API that would really help if exposed. I've experimented with exposing it in the engine and will open a PR once I've had a little more time to refine it.

The rough idea would be something that allows us to create a dart:ui Path from an SVG data string, using already existing Skia API to do so. Proposed method is static Path Path.parseFromSvgData(String svgData) -> Path

That still leaves some work around parsing out the various transformations/strokes/fills that can be applied. I think we can borrow a good amount of that from work @amirh did (I didn't borrow all his path parsing logic because it seemed like it might have constraints SkParsePath doesn't and like SkParsePath should be more efficient since it will require only one round trip to the native side to draw the path rather than round trips for each drawing command). I also didn't end up using @matanlurey for similar reasons.

See https://github.com/flutter/flutter/blob/master/dev/tools/vitool/lib/vitool.dart, https://github.com/dnfield/flutter_svg (which is currently capable of rendering the two SVGs included in that project to a canvas), and https://github.com/dnfield/engine/tree/path_svg (which is currently also including my PathMeasure/PathMetrics related work for Lottie).

Hi @dnfield ,

Here is my take on your initial implementation. Let me just say that whatever I am going to say should make no difference to your enthusiasm and coding progress. The more you do the better because we can always use it later.

The problem I have is architectural and here is why. In order for UI to be responsive at 60 frames/sec, each frame only has ~16ms to run before blocking the UI. So let's assume half is used by Flutter to do it's thing, that leaves 8ms for our SVG parser and there is no way to parse any SVG file and generate image in that period no matter how powerful a phone/tablet you have. So best thing to do is to target slow devices and have async code that is able to do this using multiple frames but the key is that each frame can only run up to 8ms and then it must return and pick up on the next frame.

So you can't parse the XML using dart:xml because it is not async, it will block until the whole file is parsed. Also generating the image should be async because you can't do everything in 8ms. There is no point in prematurely optimizing the code though so write the best code that can be read. I have a plan that will work but it will take some time so I want you do continue as you are because I can always take your work and use it later. My design plugs into the current image loading functionality (AssetImage & NetworkImage) and the user just needs to specify a '.svg' instead of '.png'.

Carlos.

@cbazza just an idea: Parsing could be done in an isolate. I think there was some work done to be able to communicate with message channels from isolates others than the UI isolate and to pass data between isolates by reference instead of copying (not sure about status or progress though)

@cbazza - thanks. I don't think that dart_xml is the best solution for this, but it works and enables some progress around the drawing logic (and I didn't want to block this completely while working to implement an async XML parser). I also started looking at implementing ImageProvider, but I figure that can be an implementation detail we can obscure from the users.

I am in no way set on any of this API. But we can at least start on drawing SVGs, and probably support simple ones on decent phones.

Are you intending to work on the XML/SVG reading/parsing API?

@zoechi - we could still achieve much better memory usage and probably better parsing time with a streaming reader model.

@zoechi yes I looked at isolates but you can only pass primitive values (null, num, bool, double, String) and lists and maps, and not objects and/or object trees, so async route seemed better. Another interesting thing about figuring out async xml parsing is that the concepts would apply to any async tree processing, like for example the widget or element tree. This would enable async reconciliation for example like in React's Fiber :)

@dnfield yes I am working on async xml/svg parser/processor.

just wondering, rendering SVG using a web-view can be an option?

Too heavy for simple buttons and I am not sure the webview will be able to handle 60 frames/sec changes. I mean let's say we move the icon around or scale it for example.

I'm not iOS developer, so I see now that also iOS 11 has support for vector assets. It's not SVG, but PDF. Is easier to support PDF vector assets?

No. Quartz has a lot of historical ties to PDF for its internal rendering system, which makes it easier to do this on an iOS device. Skia is not a PDF renderer, and the file format would (IMO) introduce a lot of ambiguity about what's supported and what's not (with not-as-good tooling to fix it available).

PDF is more complicated than SVG and the PDF/X subset (which is used for vector assets) is designed for printing. I would love to see PDF rendering support on Flutter though but for us let's stick to SVG.

I'd be happy with mere VectorDrawable subset of svg (point, line, curve, fill, move). Flutter allows for RAD and aims to be truly multiplatform (with desktop coming) but now it can not. Both Android and Apple platforms are present on 60"+ 4HD screens. There vector graphics is a must.

P.S. Excuse me, but without VG your (flutter team) work is going to vanish in wake of Kotlin working natively on many platforms including iOS. Sure Kotlin native its still in beta but so is Flutter. :(

@ohir Please explain how you would write a cross platform view (single code) that works both on iOS and Android with Kotlin native. Unless you intend to make a kotlin version of react native widget abstraction?

Let's not underestimate what the Kotlin native people will do because the possibilities are endless. I got to Flutter from my experiments creating something like Flutter using Cocos2d-x. They could use that too and/or React Native and/or Flutter because everything is open sourced and available for cross pollination :)

Yeah totally agree, kotlin love and adoption from developers is huge and cross platform compilation makes possibilities endless. But the comparison between Flutter beta and Kotlin native beta for mobile cross platform today is pointless.
Anyway, deviating from the subject.

@lukaspili So far there is anko for Android. Its layouts DSL could work intact also with apko, linko and winko* included in respective platform subtree. But this is OT for the Flutter VG issue. [* does not exist yet].

Thanks for all the passionate conversation! We'd like to keep this issue focused on the use cases and requirements for vector formats and APIs. Thanks in advance for staying on topic! :)

What do people think of splitting this into an issue for supporting SVG and keeping this one for some TBD flutter vector format?

That would make sense to me; the original issue is phrased as a Flutter-specific vector format of some kind.

@cbazza Hooray for svg-like support. I have a bunch of non-icon svgs that I use to basically draw the whole UI of an app. How should I send them to you?

Would love to try moving to flutter but generating a zillion pngs is going to seriously bloat app size and look ugly.

yes, please send me an URL to look at the files.

So at this point, on this front, I'm pursuing a Flatbuffer based approach. I'm working on defining a Flatbuffer schema that could capture vector drawing commands - more or less the way Skia captures paths.

I could see this being semi-interoperable with SVG (e.g. have a SVG -> Flatbuffer conversion tool, or Android Vector Drawable XML -> Flatbuffer, that could cover many of SVGs use cases), and avoid a lot of the performance hits that we'd face with SVG (lack of streaming XML parsing, need to parse SVG path data and then send it to native bit by bit). I've also been able to produce smaller binary files than the SVG format (although it remains to be seen how well that will scale).

It should also be possible to give more clarity up front in the conversion tooling about what features are not supported in a given SVG (e.g. "ForeignElements are not supported by this format").

The Flatbuffer parsing bit could be done in Dart or C++ - the one thing in dart is that it'd still be nice to have some way to batch commands over to Skia for building paths and drawing on Canvas.

there is a potentially much simpler solution which is to perform a compile-time parsing and digest of SVG to Skia node operations ... this would eliminate the runtime parsing of SVG altogether and allow retained mode caching of intermediate buffers

@sandrobilbeisi you mean like https://github.com/amirh/flutter/commit/69de4bbf3177d9766a386c55b27a12619da43a05 ?

that's noteworthy ... and there's also vitool https://github.com/flutter/flutter/blob/master/dev/tools/vitool/lib/vitool.dart

but I was thinking more as a build step like the one Xcode uses with SVG assets for iOS deliverables

@sandrobilbeisi do you mean creating bitmap from svgs during compile time?

BTW the Xamarin package ffimageloading caches the rendered bitmaps so only one time rendering. It also caches network images and resized images which makes it really fast

not bitmap , but Skia which is originally a vector graphics engine for <canvas>
https://skia.org/ ( p.s. acquired by Google a dozen years ago : http://www.satine.org/archives/2007/03/05/the-skia-source-code-dilemma/ )

You mean converting svg into a skia image format?

yes

@cbazza link to SVG test files: https://github.com/slingshotapp/artwork

Is there a way to run vitool at project level? I can create the generated file but it needs access to lots of private classes that prevent me from adding the .g.dart to my project.

Referring to the tool at <flutter>/dev/tools/vitool: #dart bin/main.dart --asset-name=_$hello --output=here.g.dart ./test_assets/horizontal_bar_relative.svg

@emilieroberts Thanks but those files are not in SVG format but rather on the custom android vector format which is very similar to SVG.

@cbazza oops, indeed - most of the svgs are up there now :)

@cbazza can you clarify what you mean with custom android vector? They have an <svg tag, unlike android vector drawables.

Whatever it's being done with vitool at the moment is amazing, but I couldn't find a trace of documentation anywhere. I can write it an example with AnimatedIcons.arrow_menu, but I'd also like to know what it would take to do that from assets from outside flutter SDK.

@fmatosqg you are right, the code that's used to run animations generated by vitool is private to the framework. The reason is that there are still open questions around what would be a good vector format for Flutter (as tracked in this issue), and I wanted to avoid a public API that supports any specific format (as that will be committing to that format if we don't want breaking changes in the future).
The current API surface for AnimatedIcon allows us to use files generated by vitool internally in the framework, and still be able to replace the underlying implementation and vector format without breaking any client.

If you want to generate files with vitool and use it in your project, you can do it by copying the code from packages/flutter/lib/src/material/animated_icons and including it as part of your project (this also guarantees that your project won't break if we change machinery the used by AnimatedIcon).

Sorry for the inconvenience and hope we get a better solution soon.

I like this idea, specially if https://github.com/flutter/flutter/issues/13834 goes forward. I believe such a thing should not be part of a monolithic SDK, but not particularly concerned if it's an official or community package.

There is a compact format for subset of svg coined for Shiny (Go desktop framework) by someone at the big G. Its binary representation and can bring default Android launcher icon size under 100 bytes. As stated way above in the thread - and IMSO - drawing vectors should be Skia's duty, with Flutter passing a most compact representation available. Its the tooling duty to compile res/ svg files to the internal format.
[@amirh Re: open questions around what would be a good vector format]

So FWIW, in flutter_svg I've formulated the code such that all the drawing is really done by intermediate objects. The SVG related work is basically mapping SVG to those objects. There's still work to do to get that intermediate format fully stabilized (for example, I've started on text support but it is very bad right now).

I've started porting over support for Android Vector Drawables into the framework (minus support for external color and style references etc., and not yet supporting clip paths or probably some other features). It should be entirely possible to support Shiny this way as well, or really any other format. I like working through SVG for it at this point because it helps cover a lot of interesting cases to support, so that's my primary focus for now.

After reading this thread -- and a long one about JSX support -- I can't help thinking that there exists a governance issue. The Flutter team risks being pulled in a thousand different directions as developer's clamor for what _they_ feel is important. Perhaps Flutter should institute "incubator" projects, like Apache. Requested features are implemented by plugins, in an open-source manner, possibly with contributions from the Flutter team themselves. If the plugins achieve sufficient support, efficacy and popularity, they become candidates for inclusion in the core Flutter framework.

I feel this would let the most vocal developers put their "code where there mouth is" rather than resorting to the chest- and brow-beating on display here, and would leave the Flutter team more free to concentrate on core engineering.

I respectfully disagree. If you look into the milestones like bucket5 you'll know what the team is working on and if you go to bucket6 you know what they consider a priority. Also you can know what they don't consider urgent if you look at other milestones down the road.

Also the reason to have something added to the flutter core should be more than "I can do a plugin and it works for everybody and everybody wants it". That's a reason to create a plugin, but not enough to be added to this repo or other flutter repos.

An example of things that should not be plugins: things that @dnfield added to the engine so he could benefit and use from the plugin he owns. Such plugin would have no chance of doing all the features it does if they were not added to the engine.

Being vocal is important, but will never guarantee that it will go through. Putting the code where the mouth is is also important but still not enough. This project has a lot of transparency and they clearly listen to what devs say, but it is not a democracy and doesn't mean popular vote will win without reasoning about consequences.

Yes, please don't be concerned that the developers working on Flutter's framework will be distracted by discussions on bugs. :-) We do read the discussions, and we care very much about everyone's opinions, but at the end of the day we have clear guiding principles and we're not going to just react to the loudest voices. We perform careful market analysis to determine what the community as a whole cares about.

Interesting conversation that leaves me with a simple question. How does Flutter team recommend we go from design phase (SVG) to vector graphics in Flutter?

@lukepighetti you can try https://github.com/dnfield/flutter_svg and check how far it takes you.

Personally I am not happy with the solution offered for SVG files in Flutter. I used flutter_svg package and I'm not happy with it.

SVG support needs to be supported natively in my opinion in the standard library. If we're going to start using Flutter on bigger screens like desktop apps and websites this is a must.

@socialmammoth can you elaborate on what deficiencies you're seeing?

One thing I've been mulling over for a while is whether it'd be worthwhile to support the .skp (SKIAPICT) format. I think there are good reasons to not do this directly - the format is not guarnateed to be stable from version to version of Skia being the big one.

However, it does have some interesting properties - in particular, it's possible to get Chrome/Chromium to generate an SKP (perhaps of a rendered SVG), and it's very likely that we already support most or all of the Skia drawing commands required to actually render the vast majority of SKPs.

I've been planning to create a code-gen type of solution for the SVG plugin, so that you could generate Dart/Flutter code from an SVG. I think at this point that it would probably be more interesting to investigate an SKP to Dart build process - some of the code written for Flutter SVG could be ported over to the framework (e.g. the RawPicture and related infrastructure, which roughly corresponds to a RawImage), and we could wire something up that would take the output of an SKP (perhaps generated from an SVG as rendered by Chrome, which is pretty much gold standard for SVG rendering anyway). It should be possible to make tooling that would take an SVG, invoke headless Chromium to render it to an SKP, and then transforming the SKP to some Dart file(s) that Flutter could render at runtime.

One large area this doesn't solve is dynamically loading a vector graphic at runtime (e.g. SvgPicture.network), but I'm interested in feedback on whether this would still be a worthwhile/acceptable solution even with that limitation.

I also say this with the belief that, at this point, we will never get "native" support for SVG in Flutter. This is partly because SVG itself has a lot of baggage (XML, CSS, ability to fetch external assets) that are non-trivial to implement outside of a browser/HTML rendering software and would add a lot of bloat to software we're trying to lean down. It's also partly because it's entirely possible to implement quite a bit of SVG without making any huge changes to the framework - although a few things (filterEffects and textPaths in particular right now) will probably benefit from some more tweaks to the engine.

I think being able to load SVGs directly from the network is a major benefit even if it means we only support a subset of the format's functionality.

Having a Flutter-specific vectorial format sounds like what Android is doing with VectorDrawables, which while it works fine, it also means that can't benefit from a lot of the tooling that already exists for SVG. It also makes it awkward to iterate designs because of all the format conversions.

I would like to see Flutter support SVGs natively because that is what front end devs expect from their frameworks in 2018. I would like front end devs to find Flutter accessible, because I want the ecosystem to grow.

@dnfield

.skp (SKIAPICT) format. I think there are good reasons to not do this directly - the format is not guarnateed to be stable from version to version of Skia being the big one.

IMHO interesting approach. But then Flutter tooling (at least in AS) need to seamlessly deal with conversion. Designers are somewhat used to restrictions imposed by current Android's vector-drawable imports, so they surely will be able to deal with other set of dos and donts.

For the casual developer the manual should read: "Drop your svg drawings here, annotate here, use at will. If your svg does not abide to supported SVG subset (see here) compiler or analyzer (flutter analyze) will tell you what is wrong in your svg". Or something like that.

@dnfield

get Chrome/Chromium to generate

Good for PoC and testing, but real solution IMHO may not require such a huge dependency -- and one that is hard to script as CI middle step. Of course at the beta and then as a second 'hard way' it might be ok -- eg. to get easy animated drawing that skPicture allows for. I may be wrong ofc. as designers usually have a big bucket with browsers under their laptop flap. Nonetheless, mind that artwork mutates often. Not only at prototyping stage but also as launch time approaches and devs are in bug hunting fever.

[Ie. We either need a flutter tools deal with conformant svg import or we need a way where chromium is entirely at designer's hands. Not developer's.]

PS. The launcher_icons package way might do at start: flutter packages pub run flutter_svg_to_skp:main -i path/to/svgs -o path/to/skps.

-- my ¢2

@cachapa

being able to load SVGs directly from the network

This is a work for a separate huge package that will deal with validation and workarounds
around possible incompatibilities and producer's quirks.
First get engine to draw developer's supplied vector format that "Load SVG from network" package will surely use. :)

Just to be clear @cachapa and @ohir - flutter_svg _already_ supports loading an SVG over the network (SvgPicture.network). However, that package will never end up supporting the entirety of the SVG specification - the goal is really only to support enough of the specification to render most SVGs. It already does that, with the major exceptions at this point being fliterEffects (so no blurs, color filters, etc.) and a lot of text related support - but there are some others (markers aren't supported, certian types of xlink:href references still aren't supported). There are also some issues that I am intentionally not supporting, like the full CSS specification, scripting, and interactivity.

@lukepighetti I think that expectation only really exists with web based front end developers. Qt supports SVG, but only a limited subset. GNOME supports a bit more with librsvg, but again that has some issues (and it's really difficult to use outside of Linux environments). I'm excited to see what happens with resvg, but I don't know of any GUI library that's integrating it.

@dnfield I don't want to criticize your work since you did a great job and I thank you tremendously for that. I'm just disappointed that color does not work as expected. I had to pick my own color, I'm not an artist, I'm also colorblind.

Flutter needs to support SVGs the same way modern browsers do. It's a must. We need to be able to use assets copied or imported directly from a web page without modification.

Frankly thank god at least there's a package, but we need color, we need effects, if performance is an issue than make it optional for people to turn features off not force them to turn features on.

We need full spec support for SVGs. I agree with @lukepighetti . With Hummingbird, this is a must, or web devs will laugh at Flutter and give it a hard pass.

Even @yjbanov mentions it in his article here: https://medium.com/flutter-io/hummingbird-building-flutter-for-the-web-e687c2a023a8

Since @dnfield mentioned 'resvg', @SocialMammoth perhaps flutter_svg should also aim for 'SVG static' support instead of complete svg support:
http://www.w3.org/TR/SVG11/feature#SVG-static,
which I think should make everyone happy.

Even Chrome doesn't support all SVG features and especially right-to-left text rendering is buggy (without any progress in last few years). In other words, I don't think the full SVG support is realistic. SVG-static seems to be a reasonable subset. In flutter_svg I miss text hadling (incl. text on path), filters and masks. It would be nice to have support in Flutter for building something like this https://drifted.in/horologium-app/

@SocialMammoth

Flutter needs to support SVGs the same way modern browsers do

No. Flutter apps need to be lean. This issue is not about almighty package to deal with all of SVG, it explicitly says "support a vector drawable format" (not support SVG). The goal, as I understand it, so far is to get all flutter apps rid of bitmap assets as much as possible. And that on the engine level. @dnfield did a great job via a package. Now its time to just get some vector graphics available from Dart without ballooning the flutter (skia) engine or the app itself. The .skp use seems a good choice for that goal. It already allows for more than Android's vector-drawable does and it already is in the engine. Designers will accommodate to its feature set.

@ohir I guess we disagree then. A front-end framework that doesn't support SVG files is a bad joke really.

Well, I don't think flutter NEEDS svg to be useful, but it would be nice. And if not svg, than some format that is easy to obtain from your typical vector graphics application.

Basically SVG is the standard vector format to use here but we can't possibly expect support for every feature of SVG. The goal has always been to support the minimum in order to import vector assets from typical vector graphics applications. Which vector graphics applications can read & write .skp ?

My test for if a vector format is ubiquitous enough is if it's available in Adobe Illustrator, Affinity Designer, and Inkscape. As far as I know that pretty much leaves SVG. And I agree that we don't need every SVG feature. Just basic paths strokes and fills is fine.

I can't say this with authority but I suspect it would be easier to implement a subset of SVG than it would be to convince vector graphics applications to support .skp?

@lukepighetti : Dan's idea is to use engine's internal format. The crux of this solution is to get SVG converted to the format the engine understands. It does not matter if Inkscape knows this format as long as any viable converter does exist.

I was in doubt yesterday, but today, after a bit of research, seems to me that chrome automation is well supported. If headless chrome can be used with a rendering proxy it can be made a svg->skp converter too. A bit heavy, but affordable. Low hanging fruit indeed, @dnfield :).

It all fits nicely with goals set by @Hixie almost three years ago.

@dnfield please correct me if I am wrong.
I am assuming that .skp is basically the binary format for a Skia Picture.

Given that dart:ui also has a wrapper for Skia Picture that can be generated from Dart land, won't the contents of these pictures contain different Skia capabilities? Basically the one from Chrome will use all Skia functionality, while the one from dart:ui will not (limited by what was made available via Flutter engine)? Kind of weird for the 'performance' argument, isn't it? Flutter engine & dart:ui removes all of Skia that was deemed slow (without showing performance numbers) but then you can use all of that if it comes in via the Chrome generated .skp file?

Another thing, when using .skp how would you specify the colors of an icon, if for example the icon uses 2 colors or more?

How about the old argument that by using Dart in Flutter you have control over every pixel? To me flutter_svg package supporting 'svg static' is the way to go because it will enable future innovation in Dart land. By bypassing Dart and just letting C++ handle it, it seems like Dart couldn't hack it.

Skia seems to support SVG. Why doesn't Flutter provide SVG support directly?

From what I can tell the Flutter team wants to keep the Skia package size as small as possible. I did not know that Skia supports SVG, but if it does, that is low hanging fruit. As a note, there is another issue on adding Lottie support fo Flutter because Skia supports it.

Skia does not support importing drawings from SVG, but has some experimental support for creating SVGs (which isn't as useful here).

And yes, package size is a concern.

Please if you want to ask for SVG support see: https://github.com/flutter/flutter/issues/15501

This bug is specifically about supporting vector graphics without supporting SVG.

For people who are interesting in a vector graphics format, I am curious about your use cases.

I am aware of these so far:

• Icons. Static images that may need to be recoloured dynamically (e.g. grayed out when disabled), and may need to have varying levels of detail depending on the target render size. Unlikely to have text.

• Animated icons: Two icons as described above, and a description of how to seamlessly transition from one to another.

• Backdrops: Images that may be much larger than the screen, maybe shown with parallax; generally simple scenes with shapes, gradients, and shadows, unlikely to have text.

Are there other use cases that motivate your need for vector graphics? Please describe them here. Thanks.

Supporting multiple resolutions with a single graphic, particularly with forwards compatibility for higher resolution screens

My app is basically a companion to a conference. I want to include maps of the hotel, with the ability to pan and zoom. Using a high-resolution raster is impractical for size and performance reasons; vector graphics are perfect.

Right now I'm using an embedded PDF webview, which is super inconvenient and only works online (though I could probably work around that if I had to).

• Custom 'look-alike real' knobs are practically unattainable without vector graphics. Especially ones that rotate, skew or melt shear.

To add to what Dan has said: mere 1kB of vector source can produce fine detail, smooth picture both on 7" tablet and on 105" 4HD TV. Recent case from cash register Kiosk app for 10 or 14" (cashier facing) and 5 or 7" (customer facing) screens. Set of all 5000+ vector drawings of goodies was less than 5MB in size. Just 'vegetables' subset (~150) of it converted to pngs for exact two screens used was over 30MB. Full inventory set might end in GBytes range.

P.S. Next big thing would be to have vector graphics with touch regions defined, eg, via a chosen fill. This would have spared thousands lines of code for the whole class of mostly static but detail rich interfaces.
As in interactive Machinery Operator's Manuals.

Dreams aside - just let our designers use simple vector drawings first :)

Thanks for the feedback so far. Very helpful.

@ohir Can you elaborate on "rotate, skew or melt"?

My workaround for this that I'm actually very happy with is to use the path_parsing package (https://pub.dev/packages/path_parsing) to generate canvas drawing commands from an SVG path string and then using those to make a CustomPainter widget that draws it. For other SVG shapes besides paths (rect, circle, etc.) I just manually translate them into drawing commands which is a little tedious but not too hard.

This works really well for simple vector icons and allows you to use the same widget with different sizes and colors throughout the app.

Here's the code: https://gist.github.com/jpotterm/7b30739e0af722baf97a397d9841d908

It could be really useful if there were an official flutter command line tool that parsed an SVG file and produced canvas drawing commands that would produce a similar result.

@Hixie
Eg. https://dribbble.com/shots/1083175-Air-conditioning-controller#
Central rotating knob and the gauge around it can be meticulously drawn with current Canvas API but it can also fit in 2Kb (xml svg) then circa 300-500B of drawable. Were vector graphics and rudimentary affine transformations from the Skia level exposed via some 'vector graphics' interface, this knob could be made alive just with applying fills to the gauge segments and rotating a path of the indicator small circle.

More important is that this whole knob, with colors and other details would be drawn exactly as designer planned - because it would be all her work just embedded. Interface of Vector drawings + fill + gradients + good designer may looks like: https://www.artua.com/app-design-deckadance/
Affine transformations at the developer's part will make such a design responsive and vibrant.
As for skew, and shear transformations: can eg. be used to model a control lever shifts.
("Melt" word-shift likely induced by Salvadore Dali's ghost ;)

/off-topic/

@jpotterm
It could be really useful if there were an official flutter command line tool that parsed an SVG file and produced canvas drawing commands that would produce a similar result.

I have produced something similar. Code generator that looks for an Annotation and, takes the specified SVG PathData and generates a getter that returns a Path object. If people want I could clean it up and open source it.

The app I contribute to is perfectly suited to vector graphics. It has hundreds of small black & white line art graphics that build up the UI. These can be tinted and resized.

Doing this in multiple colours at all different densities would be awful to do, unsustainable, and make the final package giant. These images come from hand-drawn graphics.

Thanks everyone for your feedback. Very helpful comments.

For people who are interesting in a vector graphics format, I am curious about your use cases.

Another use case is basically anything that needs dynamic graphics:

• charts
• loading bars
• drawing
• etc

I'm actually very surprised Flutter does not support that since Skia has support for a subset of SVG (the useful parts anyway).

I would like to use SVGs for art. A quality full screen tablet PNG can be 2mb or more, while it's equivalent SVG can be 5-10kb. Add a few screens, and we're talking 20mb to the package instead of 100kb.

For programmatic graphics I'm a huge fan of CustomPaint so I would never use SVG for things like charts, loading bars, drawing, etc. For those who are concerned about CustomPaint API, it's mentally a lot like HTML Canvas API. And yes, while I agree that it is expensive to write stuff out in CustomPaint, what you get in the end is rock solid and renders very fast and very beautifully.

If your going to support SVG, then you have to support all the SVG features, like gradients, strokes and more. This wasn't done in the Android project and that raises some warnings flag for developers, since almost all the others dev. platforms support SVG and vectors. It's the basics of graphics, do it right!

@harounhajem please see https://github.com/flutter/flutter/issues/15501 for that topic, as well as https://github.com/dnfield/flutter_svg

@PierBover for charts specifically please consider https://pub.dev/packages/charts_flutter

I just jumped into Flutter. I was refactoring a personal app from Ionic 3 to Ionic 4 and it was (again) totally different and it required an app from scratch.
So I decided to move to Flutter and give it a try. As I said, I had this app finished and working and this includes a lot of graphics and icons that I had ready on my app. I'm not a designer and I need to pay for this designs.
I understand I'm not the only one on this situation, wanting to reuse his SVG assets.

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

(not sure why is not this closed then)

Because the actual issue—support a vector drawable format other than SVG—is not solved?

oh, my fault @jonahgreenthal. I came here looking for SVG support and saw that the third comment was asking for the same thing

Uber has done this for iOS: https://github.com/uber/cyborg
It would be interesting to see something like it in Flutter.

Any updates on this?

@dnfield that worked fine displaying an svg as new widget but it doesn't work with AssetImage property. I need to display it using a CircleAvatar widget

@Hixie there is also a use case where svg icon need to have multiple color as it help the user to understand the meaning of the icon. So I hope the solution will include the ability to customize theme color as well.

Currently, some people suggest to convert SVG into font and use it the same way the icons package did however we cannot have multiple color in the icon in this case.

4 years of various comments without any useful solution. In short - no, not, possible. No, not planned.

Can we at least know why is this so problematic/difficult?

Flutter_svg has decent support for SVG in flutter. Rive also supports a vector based format for flutter.

This issue is about creating a new vector based format. That takes time :)

@dnfield there are some widget with background properties that we cannot pass svgs. Is there any way to archive this?

please add proper svg support instead of creating a new format. Svg is the de facto standard.

Whenever I create an app, usually there's an associated website, and websites use svg, and they use beautifully animated svgs, which are lightweight and beautiful at any resolution.
It would really make sense to just reuse those animated svgs in Flutter so that consistency can be properly achieved instead of having images and animations be re-implemented!

SVG already exists, works, and is widely available used and supported everywhere else. Focus on that is what we need.

This issue is about creating a new vector based format

So you mean, this issue is about reinventing the wheel, right? I agree with @d-silveira - better add built in, proper support for svg, we don't need any new vector based format.

Yes, it's about inventing a better wheel. SVG is already supported in Flutter using flutter_svg.

Better to be able to import svg and process them internally, either at build time or auto generate code during import. Similar as native Android - you can import svg and Android path definition xml will be generated from source svg. Import into Flutter project could generate dart code to be reused to draw vector asset.

@Hixie is good to make things better, I won't discuss that, but how can we support some widgets that only allow non svg images in the meantime? (for example the ones with background properties)

That would be a feature request for flutter_svg.

@Hixie Flutter SVG could create an image there, but it would be nice if the framework were more tollerant of taking pictures rather than images in some cases. Filed https://github.com/flutter/flutter/issues/49712

flutter_svg

Why is that? This is not related at all with flutter_svg package:

CircleAvatar(
  backgroundImage: MySVGImage(),
)

@Hixie flutter_svg will only ever work for some of the cases. Let me give you a practical example: I need to consume a REST API which in some of it's endpoints returns images urls. The images are user generated in a backoffice, hence some of them are png, some are jpg and some are svg. The backoffice doesn't include the file extension in the url, and does not support HEAD, so we have no way of knowing the image type ahead of time.
The expected behaviour of flutter would be to receive the url in image.network and handle it, instead of forcing me to jump through hoops to guess what type of image it is, and if it's svg switch to flutter_svg.
All of this doesn't even take into account the fact that the flutter_svg isn't a drop-in replacement for image in every case! :p

SVG in general will only ever work for some use cases too. :-)

This specific issue is about having a non-SVG vector graphics format. If you have a different requirement, I recommend filing that as a separate issue.

From earlier discussion, some important considerations are:

• We don't want full SVG support. There is too much in the spec that is expensive, heavyweight, and/or duplicates what we already have in Flutter.
• We should emphasize in our supported format those operations are effective/efficient/optimized in our graphics engine (Skia).
• We may want to process the format at build time rather than support a full run-time interpreter.

So how does someone go about creating a new vector format for images optimized for flutter? Based on above I think that's what is being suggested...

Maybe the guys over at Rive can put together some SVG converting library. They already have a proprietary (and open source) vector engine for Flutter. @luigi-rosso

Why not to add support importing svg into Flutter project. And convert to dart code/new vector drawable etc. Note that the same situation is on native Android, that's why we don't use svg directly (which I agree does not make much sense) and import to project instead, svg is stripped from not supported and not needed functionalitites and converted into android path definition.

Isn't that good idea for Flutter?

@giaur500 This issue isn't about that. If you have a suggestion specifically about SVG, please file a separate issue.

To be fair, many of the comments in this issue are discussing SVG and Flutter.

follow

SVG is perfect for great pixel-level user interface. Properly the best so far for great pixels.

@lukepighetti Yes. They are unfortunately all off-topic and having them here will not result in any improvements to Flutter.

From earlier discussion, some important considerations are:

• We don't want full SVG support. There is too much in the spec that is expensive, heavyweight, and/or duplicates what we already have in Flutter.
• We should emphasize in our supported format those operations are effective/efficient/optimized in our graphics engine (Skia).
• We may want to process the format at build time rather than support a full run-time interpreter.

A build time tool would be great, take the vector and render all the screen densities, and add the assets as images. Apples iOS does this with PDF icons.

Better to be able to import svg and process them internally, either at build time or auto generate code during import. Similar as native Android - you can import svg and Android path definition xml will be generated from source svg. Import into Flutter project could generate dart code to be reused to draw vector asset.

i like it

@giaur500 This issue isn't about that. If you have a suggestion specifically about SVG, please file a separate issue.

New issue has been created: https://github.com/flutter/flutter/issues/63752

So what's the state of this?
Is there any intention at all of supporting something similar to VectorDrawable, or even VectorDrawable itself for those on Android?

As a developer considering adopting the ecosystem, I'd say this is a strong point that'd convince me to stay native..

I never tried it myself, but flutter svg lib used to have support for at
least key features of vector drawable like paths.

On Sat, 15 Aug 2020, 19:46 n00bmind, notifications@github.com wrote:

So what's the state of this?
Is there any intention at all of supporting something similar to
VectorDrawable, or even VectorDrawable itself for those on Android?

As a developer considering adopting the ecosystem, I'd say this is a
strong point that'd convince me to stay native..

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/1831#issuecomment-674375846,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABI4Y4LWYSYEIWI3RRSSCK3SAZKO5ANCNFSM4B3FXMMQ
.

I guess state is nothing. No conclusion exists here from this thread and also my idea to develop something similar to native vector drawable closed immediately.

Is there any reason why the flutter svg package won't work for you? We are using it with great success in one of our apps. I have never used Vector Drawable so I'm not sure how it compares to SVG.

It seems the flutter_svg package is worth a look for this kind of use case..
@lukepighetti how would you rate its performance? My usage would be just a splash image and a few icon-sized graphics here and there in the app, so nothing fancy.

It seems the flutter_svg package is worth a look for this kind of use case..

@lukepighetti how would you rate its performance? My usage would be just a splash image and a few icon-sized graphics here and there in the app, so nothing fancy.

I would rate it very high for your use case. I think people should really give it a try before they put pressure on the flutter team to do something internally.

@lukepighetti

before they put pressure on the flutter team to do something internally.

Real problem with this particular issue is that Skia the flutter graphics engine has everything needed to make "drawable-like" vector format running at the highest speed without importing quite heavy dart package that calls engine to draw primitives step by step.

I think people should really give it _(svg package)_ a try

I think that people should loudly and in every possible place call Googlers to this gh-issue, because now — after four years — only negative PR may kick someone's at Google to think about whether mobile framework in year 2020 should really be forcing us to carry all that megabytes of raster graphics within our apps.

[@Hixie]

Unless I'm missing something, the implementation for such a flutter feature would look a lot like @dnfield 's flutter_svg package which appears to solve the use case you are describing. On top of that, the maintainer is on the core Flutter team so we can be sure of its quality. Would you feel better if this package was in https://github.com/flutter/plugins ?

If there is something I'm missing please feel free to educate me so I can learn more about this topic.

@lukepighetti

I think that "not SVG" in the issue's title should be made red, bold and flashing.

This issue is specifically not about svg format.

OP (and me) had hopes for exposing Skia's path api so the assets graphics could be represented in a compact form - ie binary of fixed endianess. Dan even did a patch to Skia that works for the flutter_svg, which in turn now allows us to use svg assets. Though still we parse xml at app run time and draw by calling the engine — also for the static assets bundled in the apk.

With proper support for the custom vector drawable format (lets name it fvd), parsing of designer work would happen once — at app build time, then object in fvd format would be thrown directly at Skia. In graphics-heavy app such approach would have enormous effect on the app size and noticeable savings on rendering time. [citing self]

I hope that above shows how I see this issue and justifies my call to have it at last done.
Even as a part of the flutter_svg library.

Flutter deserves to have yet another advantage over competing technologies.

For what it's worth, there's nothing inherently wrong with using flutter_svg, it's just that it's lacking even some very simple things, e.g. it doesn't support percentages and straight up crashes when trying to render them. This comment is not a knock on the flutter_svg library, it's just to explain to people who are saying we can just use flutter_svg.

flutter_svg seems work very well despite of not support scripting, HTML, SMIL etc.

it's looks good and we can build SVG from files assets, network or ordinary strings.