One of the main reasons Android's VectorDrawable is only a small subset of SVG is to stick to only the subset of path drawing that performs reasonably well.
How does Lottie deal with this? I know it calls to canvas directly when possible, but canvas.drawPath() is not exactly fast, either. What does the performance actually look like?
The performance does definitely depend on the complexity of the animation.
Small icons like the hamburger menu, wish list heart, hamburger arrow, etc run at 60fps. Even the main Lottie logo (http://airbnb.design/lottie/) that has pretty complex trim paths renders at ~60fps.
Masks and mattes are the feature that incur the largest performance hit because they require allocating a bitmap (8 bit for mattes and 32 bit for masks), rendering to them, then drawing them back to the canvas.
That's not an answer to how does it perform. For example if the hamburger goes from 4ms/frame to 12ms/frame then lottie is crazy expensive, even though it's still "60fps" in the test app.
What is the actual end-to-end cost? Have you measured it at all?
Are the frames drawn to a bitmap first or straight to a canvas? Can a single animation object display different parts of itself in different stages of that animation, or would a duplicate animation object be required?
If there are no masks or mattes, the animation is drawn directly to the canvas and no bitmap allocations are necessary.
If there is a matte, an 8 bit bitmap will be created and if there is a mask, a 32 bit bitmap will be created and drawn to.
An animation can only be at one stage at a time but you can easily create multiple animations. If you want to have several copies of the same animation, there is a composition caching option that will prevent you from having to deserialize and parse the composition again.
How does Lottie deal with this? I know it calls to canvas directly when possible, but canvas.drawPath() is not exactly fast, either. What does the performance actually look like?