"NewManLiving" wrote:
I have noticed differences with the 2xd box that I have. My framework as I stated in other posts is designed to offload as much as possible to tmp. right now I use the texture manager for grids only. My grid components know how to manage their own cache using the manager. So I always have a fixed number of images in memory at one time. Generally I have on average 10MB total in memory. I seldom go outside this and can still manage as many bitmaps as a particular grid may need
Tested on all current models enough to know that the memory is managed very well so far. Design has a lot to do with it. Sometimes you have no choice but to filter down. I don't have the extensive experience as yourself so I have not encountered as many problems. But producing what I did was by no means an easy task. But well worth it.
That's exactly my point. Your code is managing the memory by explicitly calling roTextureManager.UnloadBitmap() and roTextureManager.Cleanup() when appropriate, which is the correct way to do it given the current roTextureManager implementation. If you're relying solely on the "Manager" part of the roTextureManager to manage the loading and unloading of bitmaps, that's when you run into issues if you're keeping references open or creating bitmaps directly. That's also when you're more likely to run into bitmap load failures.
Ideally, the roTextureManager would be able to check memory usage in real time, instead of assuming the memory it's allotted for itself is always available, so you wouldn't need to maintain your own caching routines.
My Channels: http://roku.permanence.com - Twitter: @TheEndlessDev
Instant Watch Browser (NetflixIWB), Aquarium Screensaver (AQUARIUM), Clever Clocks Screensaver (CLEVERCLOCKS), iTunes Podcasts (ITPC), My Channels (MYCHANNELS)
