Roku Developer Program

[phoang]

I can't seem to find much more info on roTextureManager, but is there a max number of bitmaps it can store? I'm using Texture manager to cache a list of images downloaded from urls. However, once I hit around 20 or so requests, the Texture request would start to fail (state = 4). The work around is to perform a cleanup() to the texture manager.

I was hoping texture manager can store more or I can set a max.

If the above assumption is false, what am I doing wrong?

[squirreltown]

I know it can store way more than 100, but don't know if there is a number of requests limit.
Your problem sounds like running out of memory.
how big are the files?

[NewManLiving]

You can use the r2d2_bitmaps telnet command
To see how the manager stores data

[TheEndless]

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).

[phoang]

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})

[TheEndless]

"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})

No, unfortunately not.

[EnTerr]

"TheEndless" wrote:

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

No, unfortunately not.

Why would one want to do such a thing?!
Considering roTextureManager is just image download manager.

Then again i am not sure why would one want to use roTextureManager either, seems all it does is use async downloads to tmp. Why did they give it "component" status and not just a routine in bslDefenderOfTehFaith or whatever that .brs "library" is? It feels like i am missing something here, what is it.

[TheEndless]

"EnTerr" wrote:

"TheEndless" wrote:

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

No, unfortunately not.

Why would one want to do such a thing?!
Considering roTextureManager is just image download manager.

Because it's not just a download manager. It also manages its own LRU cache, loading and unloading bitmaps from the cache as memory is needed. The problem is, it doesn't have any knowledge of bitmaps created outside of its cache. It just assumes that X amount of memory is available to it, and manages the memory based on that. If you have bitmaps created outside of it, it can overrun the available memory, causing issues. If you could register a bitmap with it, so it's aware of that memory being used, it could adjust accordingly. Of course, ultimately, it'd make a lot more sense for it to actually query available memory, instead of just assuming what's available.

"EnTerr" wrote:
Then again i am not sure why would one want to use roTextureManager either, seems all it does is use async downloads to tmp. Why did they give it "component" status and not just a routine in bslDefenderOfTehFaith or whatever that .brs "library" is? It feels like i am missing something here, what is it.

It doesn't just download the images asynchronously, it also creates (and scales, if needed) the bitmaps asynchronously. If, for example, you have a screen full of posters that you want to scroll through, creating all of those synchronously can have a significant impact on framerate.

[NewManLiving]

On the 3 box there is no noticeable difference
On the grids I build I load and unload 2 to
3 rows at a time. 24 bitmaps or 2024 makes
No difference
I use a display stack to do this and push and pop
As the user scrolls. Loading and unloading .
Because of the lru cache of the manager it is quite
Elegant to watch as the textures rapidly come in
Most of the time so fast that you only get a brief
Glimpse of the loading bitmaps from time to time

On the 2 boxes there is a slower processor. And I find that
The incoming textures can bottleneck and slow things down
But it has nothing to do with the responsiveness of the grid
It just seems that nothing can move smoothly until there are a certain
Number of textures. Just try scrolling the homescreen grids they
Behave the same way. But you can work around this as well with
Some inginuity
Personally I think the texture manager is one of the best
Components for 2d developers

[EnTerr]

"TheEndless" wrote:
Because it's not just a download manager. It also manages its own LRU cache, loading and unloading bitmaps from the cache as memory is needed. The problem is, it doesn't have any knowledge of bitmaps created outside of its cache. It just assumes that X amount of memory is available to it, and manages the memory based on that. If you have bitmaps created outside of it, it can overrun the available memory, causing issues. If you could register a bitmap with it, so it's aware of that memory being used, it could adjust accordingly. Of course, ultimately, it'd make a lot more sense for it to actually query available memory, instead of just assuming what's available.

Ah, i see. So you are trying to do things sidewise, through hacking - instead of asking for a function to tell remaining free memory, you want to sneak your own resources under roTextureManager's aegis.

Who says roTextureManager does maintain a LRU cache and drops old resources? It is not documented as such - and searching the forum for "roTextureManager LRU" pops only you making the claim. I am not saying you are wrong on that (most often you are right) - but is there a canonical source to it?