Another note, which is somewhat unrelated, is that certain logic should be able to be eliminated or optimized with new features in 0.14/0.15.

Specifically, the spawn_playheads function exists to attach a playhead to a newly added Lottie. This is a good job for required components (or observers). Ideally I really want to split Svg and Lottie into their own types, rather than both being used by VelloAsset, but that feels like a different PR.

AH, one more catch: The VelloAssetBundle, VelloTextBundle and VelloSceneBundle now no longer require global transform, view visibility, or inherited visibility. Those are required components brought in by Transform and Visibility now.

Regarding the Handle names, I don't think there is a convention yet. If we look at an example of the migration from bevy, they changed struct Mesh2dHandle(pub Handle<Mesh>); to struct Mesh2d(pub Handle<Mesh>); but it's hard to find an equivalence with VelloAsset and its handle. We could use VelloAsset for the handle name but we would have to come up with another name for the wrapped struct, that's why I used VelloAssetHandle as it seemed simpler.

As for the migration to bevy 0.15 features, you're obviously right! However I didn't want to make the PR too big. I figured a first PR could make it work with 0.15 and a second PR could make it more idiomatic :)

Btw I got some errors that the vello_svg::vello::Scene and vello::Scene versions are mismatched. Not sure if you see those too. Can't tell because our Cargo.lock isn't staged.

@DJMcNab or @xStrom - Was it determined that all linebender projects will stage the Cargo.lock?

Yes I have the same errors when I run cargo check --all. It seems that vello::Scene and vello_svg::vello::Scene come from two different versions of vello, probably because I used unreleased versions, making things inconsistent.

I thought I'd chip in a little as I dabbled with this during 0.15 release candidate process, and I remember I was stuck for a few hours on why extracted entities kept piling up duplicates in the render world; As I did not know about this new retained render world feature in 0.15.

Unless 1) some sort of resource structure is implemented to keep app world entities and render world entities in sync or 2) spawn extracted entities with the TemporaryRenderEntity component so they despawn after every frame, they'll keep being spawned every frame and never be removed from the render world.

Hope it helps!

linebender/rfcs#5 led to the agreement that we would commit Cargo.lock.