I think it's an interesting idea but had a different implementation in mind. The current problem with your idea is: if I change the first frame in the second run this world not work so I would need to call it without dev mode but normally I only add frames so I would run it again in dev mode.

I can imagine that this will be very frustrating.

What I have in mind: specify a frames keyword argument or compute_frames where one can specify which frames have been changed and those will be added/updated but the whole gif or mp4 will be created.

To keep yours in mind one could specify a symbol : latest and then only non-existent frames get computed.

What do you think?

@Wikunia @TheCedarPrince Can I work on this issue?

Sure would be great to post your ideas of how to tackle this issue first as we haven't come to a conclusion yet 😄

Sure, will do that. Thanks!

@Wikunia I just needed a small clarification. The javis function being referred to in the issue, is it the render function? Sorry, I was not able to find any other references to it. Thanks.

Yes will update that. In the first versions we called it javis 😄

@Wikunia @TheCedarPrince I went through the code logic for render and compute_frames. What I gather is that, this new requested functionality is constrained to the few cases when either no new video is created or the update is only due to newly added frames. As was suggested by @Wikunia to provide a frames keyword argument specifying the updated frames, wouldn't it be a bit difficult to track this yourself in case significant updates were made. I feel that at a very high level we can track the unchanged frames automatically without this argument also (this might require managing a few additional state variables). What do you think?
Please feel free to correct me if anything seems wrong, I am still quite a beginner in the usages of the language. Thanks!

@Wikunia @TheCedarPrince I tried to find why it would not affect (speed up) the rendering time even after not recomputing unchanged frames. I benchmarked the code and as usual the Image.load() required to load the frames is quite a slow computation as compared to generating the frame and saving it.
For example, on my machine loading the images (which is almost equivalent to saving the image) takes ten times more time than re-computing the frame.

Hence, this method to speed up will not work. I will play around a bit more and see any potential work-around for it otherwise you might close it.

One idea of this was that the frames stay in memory and are not loaded from a file. This might be only possible in the mp4 case at the moment though