Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How can I store the number of frames played by the previous piece of data during the progressive animated webp download process? #2350

Open
chenleejr opened this issue May 31, 2019 · 6 comments

Comments

@chenleejr
Copy link

Description

I want to add animated webp progressive loading to Fresco so that I can play the animation during the download process. But there is a problem that has been bothering me for a long time, how can I store the number of frames played by the previous piece of data. During the download process, each piece of data will continue to play from the last frame of the previous piece of data, but each piece of data will generate a separate EncodeImage and CloseableAnimatedImage. These data structures do not have uri field, so I can't map the number of frames to the data source. Is adding uri to these data structures elegant? Or is there any other better way?

@chenleejr
Copy link
Author

I found a way that I think is acceptable. I store the frame number data in AbstractDraweeController and set it to the next Drawable. This way requires creating an interface in the Drawee module, and AnimatorDrawable2 implements this interface.

@oprisnik
Copy link
Contributor

oprisnik commented May 31, 2019

Awesome that you'd like to contribute to Fresco.
IMO the AbstractDraweeController shouldn't hold any information specific to 1 given image format. Ideally, you wouldn't need to recreate the whole drawable but just re-use it with the additional data. As for holding the information, maybe a ControllerListener that makes use of onIntermediateImageSet can be used for this in combination with an AnimationListener.

In general, adding clean support for this is quite cumbersome since the whole pipeline wasn't really designed to support this.

@chenleejr
Copy link
Author

Reusing the drawable is a good idea.

Another problem, I need to add an Animator parameter to the onIntermediateImageSet to call the Animator's start. Another way is to start playing the animation in createDrawable. I think it's more appropriate to play the animation in the onIntermediateImageSet, but the change in this way will be very large, or should I add a three-parameter onIntermediateImageSet to the ControllerListener?

@oprisnik
Copy link
Contributor

oprisnik commented Jun 3, 2019

Changing public APIs, especially for listeners that are widely used is something that we try to avoid so that we don't break all users of Fresco and need to bump our major version number.
Maybe a better alternative is a custom view, similar to SimpleDraweeView with extensions to facilitate that behavior. You know which Drawable you currently have and can then properly update when the intermediate image is set etc.

An alternative would be: The whole animated image rendering pipeline uses BitmapAnimationBackend under the hood, so you could add a new streaming version and then update frame data once more image data has been downloaded.
One of the big questions is how this should actually work: If you have x out of n frames streamed to the client, would those x frames repeat? Would it be "stuck" at the last local frame x until x+1 arrives? I think that the latter is the desired behavior.

@chenleejr
Copy link
Author

You are right, changing the listener is not a suitable way, I will try the custom view in the next few days, thank you very much for your advice!
For the last question, my colleagues and I agree that the latter is more reasonable, just like video play behavior, and so far my program is running according to this behavior.

@chenleejr
Copy link
Author

Thanks to your help, I have completed this feature and submitted a pull request. I would like to ask when my code will be reviewed? Or what else do I need to do?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants