Roku Developer Program

[NewManLiving]

There is no explicit documentation as far as I
Know ( tried to find this )
But it definitely can be observed.

[RokuJoel]

@EnTerr: I asked the engineer responsible for roTextureManager your question:

"Does roTextureManager really maintain LRU cache of resources, flushing the old ones as not to run out of memory (if so should be documented!) - or is it an urban legend? See viewtopic.php?f=34&t=69730#p441106 "

He Said that TheEndless' response on this thread:

"TheEndless" wrote:
The number of bitmaps it can cache is inconsequential. It's entirely dependent on the dimensions of the images, and it varies across the different Roku platforms. In general, as long as you don't have video playing in the background, you can rely on the roTextureManager's built-in LRU cache to manage its memory. It should only run out if you keep references open to the bitmaps it creates and/or have a number of bitmaps in memory that it's not managing (i.e., created with CreatObject("roBitmap") instead of a roTextureRequest).

Is the most accurate description.

- Joel

[NewManLiving]

Can you ask the engineer if unload bitmap calls cancel request
If the bitmap is in a transitional state. In other words
Is unload bitmap coded to recognize the state
And take appropriate action by calling cancel
Request if the bitmap has not reached a state
Of 3. I say this pertaining to bitmaps that may
Be in queue but not yet removed. It would help
To know what takes place when these functions
Are called during the various states of the texture
Transfer

[RokuJoel]

I can ask, but why not just call ifTextureManager.CancelRequest(request as object) and then call unload?

- Joel

-

[NewManLiving]

Because it's an additional function call. I'm just trying to optimize
My grid cache that prefetches and unloads as the user scrolls the
Grid. When the user is in a fast scroll everything moves quickly
So the request may be scrolled out and cancelled before it is even received
But quite frankly the method I use now works very well even in the lower models
I just like to know what's going on. There is very little documentation
Even the example tests for a valid bitmap when the status code is 3
Why is this? I've noticed under certain circumstances esp the longer the interval
Between a request and clearing the queue there may be an invalid bitmap
With a status code of 3. It just helps to be more clear about these things
Instead of spending time discovering the various issues and anomalies
Obviously the engineer who wrote it should be able to
Provide some insight
Thanks for your response

[TheEndless]

"NewManLiving" wrote:
Can you ask the engineer if unload bitmap calls cancel request
If the bitmap is in a transitional state. In other words
Is unload bitmap coded to recognize the state
And take appropriate action by calling cancel
Request if the bitmap has not reached a state
Of 3. I say this pertaining to bitmaps that may
Be in queue but not yet removed. It would help
To know what takes place when these functions
Are called during the various states of the texture
Transfer

If you still have a reference to the roTextureRequest, can't you test this yourself by calling GetState() to see if it's changed to Cancelled after you called UnloadBitmap?

[NewManLiving]

Yes that is what I do now. Also can store the status code in the object that holds
The bitmap (if you use an object as I do) or just test the objects bitmap handle
There are a number of ways more or less efficient. Just looking for a better
Understanding of how it all works. For example EnTerr's question concerning
The lru should already have been documented. Your answer was affirmative
Mine was based on observation. The texture manager is a critical component
For API developers one reason being limited memory. So I feel that it should
Be better explained. It took me several months to work out some of the problems
I came across particularly with fast scroll as I mentioned earlier
But all said and done. It was worth it

[NewManLiving]

"TheEndless" wrote:

"NewManLiving" wrote:
Can you ask the engineer if unload bitmap calls cancel request
If the bitmap is in a transitional state. In other words
Is unload bitmap coded to recognize the state
And take appropriate action by calling cancel
Request if the bitmap has not reached a state
Of 3. I say this pertaining to bitmaps that may
Be in queue but not yet removed. It would help
To know what takes place when these functions
Are called during the various states of the texture
Transfer

If you still have a reference to the roTextureRequest, can't you test this yourself by calling GetState() to see if it's changed to Cancelled after you called UnloadBitmap?

Just re-read your answer and no I have not tried your suggestion
I just check the status and call the appropriate function
But sounds like a good idea which never occurred to me
Will give it a try at some point. What I did do I the past
Is just call unload bitmap and did not seem to have any
Problems but they were coming in so fast that this may
Be the reason. I will give your suggestion a try and update

[kayr1m]

"phoang" wrote:
Is it possible to create an empty bitmap with the TextureManager.

e.g with roBitmap you can do this

newbitmap = CreateObject("roBitmap", {width:100, height:100, AlphaEnable:true})

Yes! However its hacky. I basically used an asset, a 1x1.png (i.e 1 pixel) trasparent and set scale mode to it. So I would load this with the dimmesions i want and it would scale to the size no problem.