I am loading stacks of images (512x512 x ~512 images)… actually a few of such … using the VL.Stride.TextureSpread.vl (from another forum post I can’t seem to find at present) because I was having huge memory issues from building a spread of filetextures.
My questions are
- Is there maybe a known memory leak and workaround, as it seems to use slightly more memory each directory load (although not as immediately troublesome as when doing it with the filetexture spread). Even in this simple form I can watch it gradually tick up with each switch (and occasionally drop a little).
- loading causes the sketch to freeze during load and it loads in two or three batched chunks. Ideally i would like if there was a way for it to animate in as it loads as many images per frame as it can without dramatic framerate drops (in this example it drops to a few fps, but in my full sketch it can take several seconds to see the next frame). It did this when I used the filetexture spread most, but not all, of the time (but again, with significant memory issues each switch). The Immutable/Dynamic/Staging pin doesn’t seem to have any affect on this, but i’m curious what it is for.
- It doesn’t seem to matter if the images are jpg, png, compressed or not as far as load times, but i’m also curious about best practices for texture files as the only post i’ve found specifically on that topic is from ~2006 and i’m sure there’ve been some changes.
System, if relevant:
RTX2070 Max Q (6GB)
. the multiple caches within foreach loops exist because in the non-simplified version I have something happening in between. I left it in place in case there’s some chance it’s relevant, but i haven’t seen evidence that it is. Removing all caching does not improve the issue and just drops framerate.
. I have tried nesting the foreach in the cache and vice versa… I’m curious if there’s a best practice on this one, but it doesn’t seem to have made any great difference.
. In the full version i also have the texturespread in a cache as it seemed to be happier there, but it otherwise doesn’t change the issues here.