Possibly. All discussions about caches and proxies and prefetching were more in a spirit of “we should re-evaluate which things work and which do not”. The result might be that some things that exist today should stay as-is, but some others might indeed make no sense anymore. No one knows which ones are which at this point.
That was in context / use case of prefetching running while you are doing a playback. While for movies/images that can be beneficial (since prefetching would be on some other thread(s) without interfering with regular playback), for scene strips that is not the case since you can’t “render them” without affecting possible “rendering” that is happening on the main thread.
Your point about “I want to prefetch for a bit and then start playback” is a valid (different) use case!
Yes. It “feels” that the cache that tries to serve all purposes today is more complexicated than it needs to be. We thought there is little reason for caching “preprocessed” and “composite” entries outside of “current frame”, so if the whole thing could be split into several dedicated caches, maybe they would become simpler, easier to reason about, and perhaps more stable / have less issues.
All of that I’ll defer to people with “design” decision power to figure out. Or hey, you are in the HQ, you can talk to them directly I frankly forgot why we did not include the points from my previous google doc about the typed channels. It was not a long discussion either.
You have correctly identified purpose of these - if you have complex stack of strips and need to tweak higher ones, it is useful to have these. I did need to enable them once from about 100 projects I have worked on. So it is super niche, but definitely needed for current frame at least.
I could have probably commented on aspect of issues and stability - The only reason, why cache is cleared / not used during rendering are scene strips. Question is, how to make VSE informed about change in any object or any property. Now I think, that only way is to hack this into 3D viewport redraw cycle notification, which is not nice, but maybe better than nothing.
Otherwise most issues with cache are very manual - each property RNA definition or operator code contains what cache needs to be invalidated. If this is not defined correctly, you can expect report about this. But I don’t think, that this could be changed easily (maybe even hardly).
The reason, why the cache is so complicated is mainly when you invalidate something, you must do it for everything, that is built on top. Also memory limiting strategy with prefetching is adding to this as I have mentioned previously.
Overall, I think the code could be nicer, but I am not sure if changing architecture would simplify things.
There is unnecessary stuff like memory pool for keys and it could be rewritten in C++. The key linking was (originally) a redundant system to catch cases where manual invalidation may be lacking. Probably much more. At the time I had pretty much no experience with C programming (or other programming lol), so the code probably looks like it.
Today, we have better performance indeed, so perhaps I wouldn’t be so nitpicky about what images to delete and what to keep.
The idea here was to remove per strip caches.
Basically we don’t cache things in some sort of longer term storage that is tied to specific strips or strip frames. (For final frame caching that will of course be stored longer term than just for one frame, but the final frame cache is not tied to strips, so it doesn’t really apply to this “remove all strip caches idea”)
However for allowing fast edits when you are tweaking or changing the compositing (or other uses where the old per strip cache would be useful), it would now instead store that information only for the current frame. (Perhaps just as a simple one dimensional list/array of images that represents the compositing order)
This new “only current frame cache” would probably be simpler than the current implementation as it would probably only need to keep track of a stack on image data that is then tossed when changing timeline position or moving around strips in the timeline.
Of course the exact design on this has not been created, but I think that it would probably be a nice thing to explore.
Strongly typed channels
The design for this has not been created yet, so Sergey rightfully pointed out that we should wait until there is actually a concrete proposal that can be read and that we can get feedback on.
No use in criticizing the idea before we can actually see exactly what it entails and what the pros/cons are.
I frankly forgot why we did not include the points from my previous google doc about the typed channels. It was not a long discussion either.