Stride keeps images in vram

[schlonzo]

hi all,

my program logic feeds different paths to the last loop of my patch. it contains the geometry and an async texture loader. I have a pool of 200 textures and display 30 once at a time, but it seems stride keeps them all in vram after being loaded once.

I had a look at the slideshow patch. Is it necessary to build the structure like that - to have an instantiated object with datatype texture - which then gets removed from the dictionary - to dispose? of the texture correctly and free up vram?

cheers

[bjoern]

@schlonzo

async texture loader

what’s that exactly?

You could try:

Need some HINTS for research - Stride - SystemOutOfMemoryException

So some more testing. I tried to make it as comparable as possible. I started the patches let them sit for a minute. Started the playback let it run for 1:30 min an then made the screenshots. The patches without the “benchmarking” seem to run a bit smoother. First of all, the SlimDX version I added performs abysmal, it reaches max 12 FPS :) Comparing the CPU load to the other approaches I assume some of the “copying” back and forth happens on the CPU. Also there is some error at startup. [G…

or a bit more tidy

VL.Stride.TexturePlayer formerly known as TextureLoader

VL.Stride.TexturePlayer_V0.2.7z (27.0 KB) Added a Speed pin and reverse playback Directory loaded async Files are explicitly (re)loaded on directory or search pattern change

[schlonzo]

I knew I read something about a vram problem with stride before.
great work on the texture player and thx for the research btw!
I will move my questions to your WIP thread.