3D Animation gallery followups

[rossbar]

Follow-up to #7025

The main things are:

• Splits the original example into 2 examples: one for view updating and a second for the random walk
• Refactor the random walk example to use attribute setting instead redrawing everything each frame

What do you think @lobpcg ?

[lobpcg]

Follow-up to #7025

The main things are:

• Splits the original example into 2 examples: one for view updating and a second for the random walk

Sure, this is easy. It looks like you have done it already?

• Refactor the random walk example to use attribute setting instead redrawing everything each frame

What do you think @lobpcg ?

I don't know how. Let me study your code.

[rossbar]

This is a PR, so these are the things I've already done - I was hoping you could take a look and make sure I didn't butcher the original intent of your examples too much! Sorry for the confusion :)

[lobpcg]

This is a PR, so these are the things I've already done - I was hoping you could take a look and make sure I didn't butcher the original intent of your examples too much! Sorry for the confusion :)

Sorry for my confusion. I'll have a look tomorrow.

[lobpcg]

Follow-up to #7025

Looks better, thanks! A few suggestions:

• keep both references in the basic example;
• use 3d spectral rather than spring in both examples - I would like to see it popularized.

Do you think that a frame redraw is never needed i.e. can always be avoided?

For a new follow up PR I would like to see a new hopefully similar example but which utilities
blit=True as in https://matplotlib.org/stable/api/animation_api.html

[lobpcg]

Finally, rather than just deleting my original module you should rename it and edit to become one of your examples, to make your changs trackable and comparable with my original.

[lobpcg]

This gives me a warning:
UserWarning: The figure layout has changed to tight
plt.tight_layout()

delete, and use
fig = plt.figure(layout='tight')
below instead

[rossbar]

The problem with this is that the "tightness" can only be determined after the axis object is added. I went ahead and used fig.tight_layout() after the fig.add_subplot call, which should be equivalent.

[lobpcg]

fig = plt.figure(layout="tight")

[rossbar]

See above

[rossbar]

Despite the fact that this PR creates two examples from one (doubling the number of animations), it still improves the total example runtime (from 11sec -> ~6sec on my local machine) compared to the version on main.

[lobpcg]

Finally, rather than just deleting my original module you should rename it and edit to become one of your examples, to make your changes trackable and comparable with my original.

Also, it may not be the best practice for a contributor to mark a suggestion as "resolved" unless possibly in trivial cases as it makes the follow-up reviewing more difficult...

[rossbar]

Finally, rather than just deleting my original module you should rename it and edit to become one of your examples, to make your changs trackable and comparable with my original.

FWIW I had done so, i.e. used git mv to rename the file into one of the split examples. However, I am not sure how you can do this across "child" files, i.e. how to maintain provenance from one parent -> two different child files.

The only thing I could think to do to alleviate this was the following:

1. Create a copy of the original example file (as-is, no content changes) to the new example file name, i.e. cp plot_3d_rotation_animation.py plot_3d_animation_walk.py
2. Commit that file with the --author tag to preserve original attribution
3. Then, git mv the original file to rename it: git mv plot_3d_rotation_animation.py plot_3d_animation_basic.py

At this point, there are two new files with content identical to the original plot_3d_rotation_animation.py file, and attribution (i.e. file authorship) is preserved for both new files.

Now, to make the changes to the file contents reviewable in github, I can squash all of the changes from the individual commits and apply them to the new files.

I couldn't figure out how to do this all with only rebasing, so I had to resort to creating a new branch and using a combination of squash and restore to map changes across branches.

[rossbar]

Closing in favor of #7681 . FWIW the changes to the content of the files are now viewable in the GitHub UI by inspecting commit fd27267