Roku Developer Program

[NewManLiving]

Hello Joel or Anyone that may be able to help

I Hope you can assist me in obtaining information on how a couple of the ifTextureManager methods work internally. These questions are only important in respect
to dynamically loading and unloading textures such as would be the case in my virtual grid, especially during fast paging sequences . This does not apply to preloading as the sending and receiving states of all textures can easily be determined.

However,I do notice that with large image sets that will exceed memory, textures have to be dynamically loaded and unloaded quickly as the user is scrolling. Now while I have had great success with this I am not quite sure what goes on under the hood. The documentation as you know is sparse which makes me wonder if anyone really knows

During the above scenario I use a display stack to pop off and unload textures and then push on and request new textures. This all works very well but I am not sure how to release the popped textures. My Current scenario (simplified) is such that when the message handler receives the texture request it checks it's state and the validity
of the bitmap. if all is well, It then sets the returned bitmap to a Bitmap field in a receiving object. The receiving object also contains a field called TRequest to which the created TextureRequest was assigned to. Each object in my cache list contains these two fields. So then I know that if The TRequest is valid but the Bitmap is Invalid then the TextureRequest was sent but not yet returned OR not yet removed from queue. Likewise I know that If both the TRequest is Valid and the Bitmap is valid then the transaction is complete. My releasing problem is only when I have a valid TRequest and no Bitmap yet. Obviously I would use UnloadBitmap if both conditions are met. but I don't quite know where the requested texture is if only the TRequest is valid. It may not have returned yet or
it may be sitting in queue. I check the queue constantly even in the easing functions that scroll the rows. I find that not removing the textures quick enough will generate a state of 3 with an invalid bitmap.

Now for my questions
Does UnloadBitmap call CancelRequest if the texture has not been returned yet or cancel/remove the texture if it is sitting in queue. This appears NOT to be the case
Is is safe to use CancelRequest on a texture that was sent but not yet received BUT may be in the queue. Currently If both conditions are met
I use UnloadBitmap, If only the TRequest is valid I use CancelRequest. Looking at the memory imprint I am able to maintain my memory goals without a problem
with no fluctuation in the established baseline. The only real issue here is basically with CancelRequest during periods when textures are constantly
loaded and unloaded.

I hope this is simple enough. Just a more detailed description of both methods and what they actually do will suffice

Thanks In Advance - John

[NewManLiving]

One other thing, I realize that I can getstate
On the texture request to determine its exact
State but I would still like to know how the
Unload and cancel methods work under the conditions
Mentioned

Thanks again

[NewManLiving]

Let me make all this as simple as possible. What I really need to know (after a good nights sleep - not after working for 16 hours then asking long-winded questions)

What interface method do I use: UnloadBitmap or CancelRequest based upon the following states of the roTextureRequest ? Some are obvious - The Ones with a question mark are not. Also do you know if either of the methods can figure out it's own state and act accordingly

State

0 Requested = CancelRequest
1 Downloading = ????
2 Downloaded = ????
3 Ready = UnloadBitmap
4 Failed = Do nothing or resend
5 Cancelled = Do nothing or resend

Thanks again I think I got it down to a concrete question