I’ve been struggling to get the drop-free movie switching that is allegedly possible with proper preloading techniques. Several Facebook group posts yielded more questions than answers so I’m re-posting here as suggested by @raganmd
Essentially I step though a group of moviefilein TOPs calling preload() method in a “Deck B” without disrupting playback of “Deck A” … in the wiki it says:
This leaves me wondering something: Is there any need to stagger calling preload such that the next index movie doesn’t get a preload call until movie at current index returns isFullyPreRead == True? I drop frames when the preloads happen on an entire scene of assets from a single script run.
I also encountered a VRAM leak: Does calling preload() on an already loaded moviefileinTOP also unload the previous memory or overwrite it? or is it necessary to call unload() for those TOPs before preload() ? Does the cacheMemory=True flag have any special considerations? The only note I saw was that it’s helpful when assets have the same res/aspect (mine do). Can it cause VRAM leak if I missed some other step? For now cacheMemory=False is my fix, but I’d like to be as efficient as possible with caching.
Along with lots of textport printing, I’ve been staring at performance monitor trying to figure this out: I see lots of “waiting for frame for 0” line items when things slow down. What does that mean? Particularly when the file is a single still frame png? I tried preload(0) to force frame 0 to be ready, also tried setting alwaysloadinitial = 1, but still sometimes see “waiting” for upwards of 18ms when the images are played played at start of scene… shouldn’t they be ready to play if I called preload()?
I’m attaching a very simplified example of my setup, but it doesn’t experience the same slowdowns as my full project… am I doing it right?
Thanks for any insights,
_Will
preloadSimpleExample_CutMod.zip (1.45 MB)