Well if you’re simply reading the data (like in most cases, especially for music notation), I would probably cache the data somehow either using a
CachedValue<SomeNotationType> or I would use the
ValueTreeObjectList I presented to have a set of concrete objects to use.
In the music notation example, I can’t see what would be updated at 60fps? Surely when you add a note that simply adds a tree? The parent then drawing that section can simply repaint itself? If you need this to be quicker, use a ValueTreeObjectList so you have a concrete bunch of objects.
In Waveform we use some properties that are constantly updating, modulating parameter values or the view start/end positions when scrolling etc. and these work fine.
You probably could get away with all path points stored to a tree and animate them but to be honest if you’re doing something like this you’ll probably have an object which represents the path, some kind of UI object running on a timer updating the path and then drawing it. When you hit save, you can flush the state of the path object to the tree, either in XML node form or simply as a blob of binary data (e.g.
Animations are a bit of a different use case as they’re not really the model’s state, they’re some kind of extrapolation of it. Think about saving and restoring the above gif. What does it mean? What would you expect to load when you started the app? Would it be halfway through? If so, how does the app know what frame to play next?
It’s probably better to think about it in terms of some “starting data”, then have a time animate that and display it.
Also, don’t worry too much about size, when you start dealing with plugins, multiple megabytes is not unusual for their state. It’s more about the frequency of updates and what you do in response to those. That’s why using async updaters etc. is worthwhile as I discussed in my talk.