Code generation support

[dnfield]

It should be entirely possible to generate the DrawableRoot and children from SVG data at compile time, thus sparing parsing.

This is a different take than trying to make things serializable, which should have a few advantages:

• No parsing time at runtime
• No concerns about future-compatibility with a serialized Path, Paint, Shader, etc.

But a few limitations:

• No support for dynamic loading of an asset over network etc. (but that could still be supported with existing implementation)

See also dnfield/flutter_path_drawing#2

[ghost]

@dnfield wow pretty cool.

Can you please design this so we can still use runtime building. Compile time building is great for stuff you know wont change, but runtime is really useful because i am working on using the SVG package with with HTML Flutter. Togather i get the ability to have everything interpreted at runtime.

[dnfield]

I have no plans to deprecate runtime loading/rendering. This would basically just allow for parsing and generating the Drawable at compile time

[dnfield]

See also https://github.com/dnfield/flutter_built_path

[dnfield]

It's looking like to do this sensibly will require decoupling the parsing logic a bit more.

Just want to make sure to not bloat up memory requirements when doing so...

[dnfield]

This is blocked by #47 - not so much because of DOM, but because parsing needs to be rewritten a bit to make this make sense.

[Leptopoda]

Hi there,
any progress on that? I've read a bit in your other repos (like flutter_built_path or flutter_path_drawing) but they seem to only apply to paths. I'd like to throw entire svg's into it and do its thing.

Am I just missing something in the other repos?

[dnfield]

I do not intend to work on this anymore, and am instead looking into working on a new package (https://github.com/dnfield/vector_graphics) that captures the spirit of this issue.