invalidating bitmaps/sprites
I have a carousel of large images. In order to optimize the amount of available memory I am trying to remove the offscreen sprites from the compositor and then invalidate them. However after i have do...
Forum Discussion
Yeah, it occurred to me that this is probably the case. i will look into that.
This is in response to your previous post:
I did not post the full code, a roscreen is defined, but not until after the first round of bitmaps is downloaded. I am using rourlttansfer to manage my bitmaps, mainly because i didn't want to have a separate get function for bitmaps and my other http get requests. Is there a benefit to using the texturemanager over an asynchronous urltransfer and then creating a bitmap from the filesystem?
There are two seperate screen stacks. I am not sure if this is the intent, but whichever screen stack is defined last ends up showing on top. So if i define a roscreen and then define a roimagecanvas it works similar to the regular screen stack. Altho both cover the whole screen.
I need a videoplayer on the screen on user initiation, however i dont want to deconstruct my roscreen / all my sprites yet. If you display the rovideoplayer on roscreen it always shows on the bottom layer below the screen and is covered by other image data. i decided to solve this by defining a new image canvas and then targeting my videoplayer and it's ui to that. Then to return to the screen i just close the image canvas.
I have a working version that displays the carousel and video and animations as intended.
The problem l am specifically having is this: over the course of navigating through the carousel of images, images are downloaded from a server before they come into view, and then a sprite is generated to add to the carousel. Other images are deleted in order to give those space. This works fine but i have to preset the number of frames it loads in each direction.
What i want to do is this: load and create bitmaps until a bitmap returns invalid when defined. Then delete the frame of images that weren't completely loaded. This will reduce the number of times i have to load.
Right now this fails during the main loading sequence. The bitmaps are loaded, one returns invalid, the sprites for the extra frame are removed, but the bitmaps for those sprites remain in memory. When a new bitmap is created to fadeout the load screen the memory is already full.
I think i may need to call screen.swapbuffers, maybe the bitmaps are not released until the buffer has cleared.
I cant test until tomorrow.
This is in response to your previous post:
I did not post the full code, a roscreen is defined, but not until after the first round of bitmaps is downloaded. I am using rourlttansfer to manage my bitmaps, mainly because i didn't want to have a separate get function for bitmaps and my other http get requests. Is there a benefit to using the texturemanager over an asynchronous urltransfer and then creating a bitmap from the filesystem?
There are two seperate screen stacks. I am not sure if this is the intent, but whichever screen stack is defined last ends up showing on top. So if i define a roscreen and then define a roimagecanvas it works similar to the regular screen stack. Altho both cover the whole screen.
I need a videoplayer on the screen on user initiation, however i dont want to deconstruct my roscreen / all my sprites yet. If you display the rovideoplayer on roscreen it always shows on the bottom layer below the screen and is covered by other image data. i decided to solve this by defining a new image canvas and then targeting my videoplayer and it's ui to that. Then to return to the screen i just close the image canvas.
I have a working version that displays the carousel and video and animations as intended.
The problem l am specifically having is this: over the course of navigating through the carousel of images, images are downloaded from a server before they come into view, and then a sprite is generated to add to the carousel. Other images are deleted in order to give those space. This works fine but i have to preset the number of frames it loads in each direction.
What i want to do is this: load and create bitmaps until a bitmap returns invalid when defined. Then delete the frame of images that weren't completely loaded. This will reduce the number of times i have to load.
Right now this fails during the main loading sequence. The bitmaps are loaded, one returns invalid, the sprites for the extra frame are removed, but the bitmaps for those sprites remain in memory. When a new bitmap is created to fadeout the load screen the memory is already full.
I think i may need to call screen.swapbuffers, maybe the bitmaps are not released until the buffer has cleared.
I cant test until tomorrow.
