Use velato independently of vello

[vadimb892]

Hello. I have some questions to velato mantainers. Can you answer them all?

1. I think velato has good lottie parsing capabilities. But it's depends from vello. Maybe it's better make velato independed of any renderer, so it can be used in more places like Wasm/browser. Can we use vello under feature? I opened PR for this already: Wasm/Browsers Support #71. Feature vello will be used by default.

2. 72 PR can't pass cargo clippy because master contains already dead code that I don't change.

3. How I can avoid unused code clippy issues in doc test lib.rs if I use pub use {kurbo, peniko};. peniko isn't used in doc test, but this reimport is requered.

Thank you for attention 🙂.

[nuzzles]

I would ideally like to separate out the lottie spec from velato as a standalone crate, e.g. cargo add lottie-spec.

In my opinion Velato is less of a lottie parser and more of a vello integration for lottie, and that's what I think the original purpose was designed for.

@dfrg @raphlinus Can probably speak to the original motivation more.

[dfrg]

In the original velato code, rendering was dispatched to a trait and the hard dependency on vello could be easily removed. See

velato/src/render.rs

Line 13 in 02594bd

pub trait RenderSink {

I’m not sure why this was changed.

[vadimb892]

@dfrg, @simbleau, thank you for the answer. I need use your lottie parser without any renderer dependency. And I can't use forks. So I interested in separating lottie parser part from vello in velato.

Do you plan to separate the lottie parser into a separate crate? If so, how can I help you speed up this process? If you agree, you can create a new lottie repository. And then I can create a new PR for the parser separation and a PR for the velato refactoring.

Or we can return back trait RenderSink and move vello under feature.

I want to hear your opinion on whether I can contribute to your work at all.

[dfrg]

I’ll let @simbleau chime in but I think restoring the RenderSink trait and making vello an optional dependency is the easiest path forward.

[nuzzles]

@dfrg, @simbleau, thank you for the answer. I need use your lottie parser without any renderer dependency. And I can't use forks. So I interested in separating lottie parser part from vello in velato.

Do you plan to separate the lottie parser into a separate crate? If so, how can I help you speed up this process? If you agree, you can create a new lottie repository. And then I can create a new PR for the parser separation and a PR for the velato refactoring.

Or we can return back trait RenderSink and move vello under feature.

I want to hear your opinion on whether I can contribute to your work at all.

Ideally I'd want to have an auto-generated Rust binding of https://lottie.github.io/lottie-spec/1.0/specs/schema/

I don't know if that fits under Linebender though. But we would use it if it was well-maintained. It could be moved under the linebender org post-creation, similar to resvg/usvg.

This was planned work (#38), but if you want to speed up the work then start a new crate called lottie_spec and use typify to generate bindings and add the typical top-level parsing methods, you'd expect from serde: e.g. from_str, from_value, et al. Advice on maintenance: I would feature-gate the type bindings, e.g. cargo features would be latest, schema-1.0, schema-1.1, etc. as new versions of the lottie spec come out.

From there, we would be able to remove all of the parser logic in velato and use the new crate as a consumer. In my opinion, this is the cleanest happy path.

I’ll let @simbleau chime in but I think restoring the RenderSink trait and making vello an optional dependency is the easiest path forward.

I don't think RenderSink disappeared, it just changed names/locations. The logic is still in velato. Regardless I had always thought Linebender was developing a universal in-memory vector format, possibly in "interpoli"? started by @waywardmonkeys. I could see us moving to that for velato.

I am good with making vello an optional dependency, though.

[dfrg]

Looks like the current code just renders directly to a vello scene: https://docs.rs/velato/latest/velato/struct.Renderer.html#method.render

[nicoburns]

anyrender::PaintScene also implements a "RenderSink` trait

[Wandalen]

Hello friends.

#71

Please review

[Wandalen]

@nicoburns @dfrg @simbleau

[nuzzles]

On vacation, I can take a look next week.

[vadimb892]

@nicoburns @dfrg @simbleau. I apologize for bothering you. I wanted to ask if there are any updates on our PR review: #71

[nuzzles]

On further look, right - Looks like the RenderSink was removed. I did that a while back when we merged vellottie, can't remember why. Regardless, I see the need for it back again.

I am interested in looking into using the AnyRender abstraction that @nicoburns may be more knowledgeable on.