Javis Animation Dev Mode

[TheCedarPrince]

Is your feature request related to a problem? Please explain.

When developing Javis animations that take hundreds of frames, I have found that when I run the render command it has to recompile and make all the hundreds of frames. I am impatient and do not want to wait when developing!

Describe the solution you'd like

Therefore, I think we could implement a kwarg like debug::Bool or dev_mode::Bool in the render function that will do the following:

1. When dev_mode == True activate development mode
2. Compile all frames currently defined in the render function and save them as image files in a temp directory
3. Finish compiling frames to filetype.

Upon running of the render function with dev_mode == True again with more frames added:

1. If development mode is still active, then check what images have been rendered
2. Skip frames that were previously rendered
3. Save new frames as image files in previous temp directory
4. Combine images together to final filetype.

Therefore, saving time on development compilation by having frames that were previously rendered be saved.

Additional context

Based on discussion with @Wikunia !

[Wikunia]

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?

[codejaeger]

@Wikunia @TheCedarPrince Can I work on this issue?

[Wikunia]

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

[codejaeger]

Sure, will do that. Thanks!

[codejaeger]

@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.

[Wikunia]

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

[codejaeger]

@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!

[codejaeger]

@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.

[Wikunia]

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