Your Digital Media Has Never Looked So Good

 
phoang
Topic Author
Posts: 6
Joined: Fri Apr 04, 2014 7:41 am

Texture Manager Limitation

Tue May 06, 2014 8:56 am

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?
 
User avatar
squirreltown
Posts: 864
Joined: Sun Apr 21, 2013 2:20 pm

Re: Texture Manager Limitation

Tue May 06, 2014 10:50 am

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?
Kinetics Screensavers
 
User avatar
NewManLiving
Posts: 452
Joined: Fri Aug 02, 2013 6:14 pm

Re: Texture Manager Limitation

Tue May 06, 2014 11:11 am

You can use the r2d2_bitmaps telnet command
To see how the manager stores data
My Channels: 2D API Framework Presentation: https://owner.roku.com/add/2M9LCVC
Updated: 11-11-2015 - Completed Keyboard interface
The Joel Channel ( Final Beta )
 
User avatar
TheEndless
** Valued Community Member **
Posts: 9231
Joined: Mon Oct 04, 2004 10:15 am
Location: US
Contact:

Re: Texture Manager Limitation

Tue May 06, 2014 1:49 pm

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).
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)
 
phoang
Topic Author
Posts: 6
Joined: Fri Apr 04, 2014 7:41 am

Re: Texture Manager Limitation

Wed May 07, 2014 1:17 pm

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})
 
User avatar
TheEndless
** Valued Community Member **
Posts: 9231
Joined: Mon Oct 04, 2004 10:15 am
Location: US
Contact:

Re: Texture Manager Limitation

Wed May 07, 2014 1:31 pm

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.
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)
 
EnTerr
** Valued Community Member **
Posts: 3834
Joined: Sun Jan 02, 2011 2:41 am

Re: Texture Manager Limitation

Wed May 07, 2014 5:45 pm

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.
 
User avatar
TheEndless
** Valued Community Member **
Posts: 9231
Joined: Mon Oct 04, 2004 10:15 am
Location: US
Contact:

Re: Texture Manager Limitation

Wed May 07, 2014 6:36 pm

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.
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)
 
User avatar
NewManLiving
Posts: 452
Joined: Fri Aug 02, 2013 6:14 pm

Re: Texture Manager Limitation

Wed May 07, 2014 7:01 pm

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
My Channels: 2D API Framework Presentation: https://owner.roku.com/add/2M9LCVC
Updated: 11-11-2015 - Completed Keyboard interface
The Joel Channel ( Final Beta )
 
EnTerr
** Valued Community Member **
Posts: 3834
Joined: Sun Jan 02, 2011 2:41 am

Re: Texture Manager Limitation

Wed May 07, 2014 7:22 pm

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?
 
User avatar
NewManLiving
Posts: 452
Joined: Fri Aug 02, 2013 6:14 pm

Re: Texture Manager Limitation

Wed May 07, 2014 7:54 pm

There is no explicit documentation as far as I
Know ( tried to find this )
But it definitely can be observed.
My Channels: 2D API Framework Presentation: https://owner.roku.com/add/2M9LCVC
Updated: 11-11-2015 - Completed Keyboard interface
The Joel Channel ( Final Beta )
 
User avatar
RokuJoel
Posts: 1758
Joined: Mon Nov 14, 2011 5:22 pm

Re: Texture Manager Limitation

Wed Jul 30, 2014 4:23 pm

@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
 
User avatar
NewManLiving
Posts: 452
Joined: Fri Aug 02, 2013 6:14 pm

Re: Texture Manager Limitation

Wed Jul 30, 2014 4:44 pm

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
My Channels: 2D API Framework Presentation: https://owner.roku.com/add/2M9LCVC
Updated: 11-11-2015 - Completed Keyboard interface
The Joel Channel ( Final Beta )
 
User avatar
RokuJoel
Posts: 1758
Joined: Mon Nov 14, 2011 5:22 pm

Re: Texture Manager Limitation

Wed Jul 30, 2014 5:17 pm

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

- Joel

-
 
User avatar
NewManLiving
Posts: 452
Joined: Fri Aug 02, 2013 6:14 pm

Re: Texture Manager Limitation

Wed Jul 30, 2014 6:41 pm

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
My Channels: 2D API Framework Presentation: https://owner.roku.com/add/2M9LCVC
Updated: 11-11-2015 - Completed Keyboard interface
The Joel Channel ( Final Beta )

Who is online

Users browsing this forum: wshirley and 2 guests