Samsung / rlottie

A platform independent standalone library that plays Lottie Animation.
Other
1.15k stars 223 forks source link

Only one asynchronous task per animation can be scheduled #517

Open pontaoski opened 2 years ago

pontaoski commented 2 years ago

The documentation doesn't mention this, so it seems like you should be able to schedule as many tasks as you want for a single animation. However, trying to do so results in a crash, and looking at the source reveals that the animation can only hold one async task at a time.

smohantty commented 2 years ago

@pontaoski , The idea of render() api returning future is user don't have to wait till the rendering finish . whenever user needs the result can get it from the future. Yes Animation instance can't render multiple frames simultaneously because internally it keeps one render tree and updates it for requested frame before rendering.

If you need to generate animation frames for a single resource , then can be done by creating 2 or more animation object with same resource and request different non-overlapping frames from respective animation object.

Just curious do you have any usecase where you need more than one frame at a time ?

pontaoski commented 2 years ago

I'm using rlottie to implement showing lottie images in a GUI app; the toolkit has an API for animated image formats that consists of essentially loadImage, numFrames, imageForFrame.

What I was hoping to do was something along the lines of this in the loadImage implementation:

std::vector<std::future<Surface>> futures;
for (int i = 0; i < numFrames; i++) {
    futures.push_back(animation.render(i));
}

so that I could queue up all the frames to render in the background, only needing to block to wait on a future if the toolkit requests a specific frame from the image with imageForFrame.

smohantty commented 2 years ago

@pontaoski , The above code will simplify your logic but will take lot of memory , as some animations have more than 1000 frames in that case you will end up creating those many buffers.

I will do something like this below.

loadImage() { Animation* obj = new Animation(); // request to render the 1st frame Future req = obj->render(0); pending_frame = 0; }

imageForFrame( reqId ) { if ( reqId == pending_frame){ req.get(); } // speculatively render the next frame Future req = obj->render(reqid++); }`

but then it all depends what the request pattern from the Uitoolkit does it needs all the frames at one time or 1 frame at a time.

pontaoski commented 2 years ago

there's no way to "cancel" a pending render, right? so i would need a second animation for the case when the toolkit requests a frame that isn't what's being rendered