I had the same thought as @dcthomp when I read this proposal. I really like most of what is proposed. But I don’t think changing the mode to always be real time is a good idea. I see several problems with that.
- As mentioned previously, simulations generally don’t time stamp their data in a time scale that is expected to be animated. If the animation has the appropriate time scale, that will be a complete coincidence. This will frustrate many users.
- Simulations commonly do not write out the simulation time. In this case, ParaView generally stamps the time as the time index. That will update the data at a rate of 1 Hz, which is almost certainly not what user’s want. You could work around that problem by changing the stamp to fractional numbers, but that would be confusing, because now the time does not match the index.
- It can be the case that the simulation writes out time steps at uneven intervals. Even so, it is common to want to play these time steps as a sequence of frames (i.e.
Snap to TimeSteps). This does not seem practical with the proposed method. - I’ve taught the tutorials of the ParaView animation several times. Even though I’d often recommend the
Real Timemode for specifying the animation time, I found that users either didn’t quite get the point or preferred usingSequencefor controlling the time sequence. I think users just like explicitly setting where the frames lie. - One of the features lost is the ability to speed up or slow down time during the animation. Although not super common, users sometimes like to stop the pipeline time for a bit during the animation (for example, to stop the simulation data, move to a new camera position, and resume the simulation data).
- The time stamps real-time mode visits vary depending on the speed of the computer and will vary from play to play. This makes specifying what times the animation visits, which is important to users, extremely awkward.