Developers

[NewManLiving]

What he means is your texturerequest must persist until completed. If you are using asynchronous services it is important that you keep your texturerequest in scope until it actually completes with a return code. Creating a texture request locally in a function and then returning from the function after sending the request will of course invalidate any local variable created in the function as well as your request.

[scorpiontahir02]

I agree. You should have only one instance of roTextureManager for the entire app. There is no point in invalidating it. But, what Im talking abt is keeping the roTextureRequest instance alive until its corresponding roTextureRequestEvent is returned.

Oh sorry you wrote roTextureRequest and I misinterpreted it with roTextureManager. And thanks for the info that we need to keep the reference to roTextureRequest until it is completed, I did not know that. But I am keeping the reference to all the roTextureRequest objects until the screen that these roTextureRequest objects belong to closes. And I am using same roTextureRequest to rerequest image in case of failure instead of creating new one.

[NewManLiving]

each time you request a texture create a new request. I reused them initially and had problems. Generally you want to keep your request in an AA by ID. You can also use an AA as a structure which contains an rotexturerequest member as well as other information that identifies the purpose of the bitmap including a bitmap member where you keep the bitmap. Keep a list of these structures in an AA by the texturerequest ID. When the request returns pull it from the list by the returning requests ID ( you will have to convert to string on both ends). In case of failure do not reuse but create a new one from the information stored in the associated structure and resend. You can also keep a resend count in the structure so you know how many times you requested it.

[scorpiontahir02]

"NewManLiving" wrote:
each time you request a texture create a new request. I reused them initially and had problems. Generally you want to keep your request in an AA by ID. You can also use an AA as a structure which contains an rotexturerequest member as well as other information that identifies the purpose of the bitmap including a bitmap member where you keep the bitmap. Keep a list of these structures in an AA by the texturerequest ID. When the request returns pull it from the list by the returning requests ID ( you will have to convert to string on both ends). In case of failure do not reuse but create a new one from the information stored in the associated structure and resend. You can also keep a resend count in the structure so you know how many times you requested it.

This is exactly what I am doing now, except for the part that I am using URL as the key in AA (I am using it like AA[url] because url contains charachters that dot(.) does not support) instead of roTextureRequest id because it makes it easy for me to use it afterwards in my application, also I am reusing previous roTextureRequest objects. So thanks for the heads up on future issues with reusing same roTextureRequest objects, I will replace my code to create new requests.

[scorpiontahir02]

One thing I would like to know though, when I am using roTextureManager, should I load my local images too using it or using CreateObject("roBitmap")? Although both will be fine but what should be the practice?

[NewManLiving]

I use roURLTranfer to file for images that I need to persist for the entire application or module. I designed my framework to load and unload these bitmaps from temp which are primarily top-level interface objects. Right now I use CreateObject for these bitmaps and the texturemanager for grid bitmaps. So far, I have not had a problem mixing the two

[scorpiontahir02]

"NewManLiving" wrote:
I use roURLTranfer to file for images that I need to persist for the entire application or module. I designed my framework to load and unload these bitmaps from temp which are primarily top-level interface objects. Right now I use CreateObject for these bitmaps and the texturemanager for grid bitmaps. So far, I have not had a problem mixing the two

Ok, actually I was talking about the image we load from pkg:/ but as you said you are using createobject for tmp:/ so using it for pkg:/ will be ok too. In roTextureManager's example I saw it to be used for pkg:/ images that is why I asked.

[TheEndless]

"scorpiontahir02" wrote:

"NewManLiving" wrote:
I use roURLTranfer to file for images that I need to persist for the entire application or module. I designed my framework to load and unload these bitmaps from temp which are primarily top-level interface objects. Right now I use CreateObject for these bitmaps and the texturemanager for grid bitmaps. So far, I have not had a problem mixing the two

Ok, actually I was talking about the image we load from pkg:/ but as you said you are using createobject for tmp:/ so using it for pkg:/ will be ok too. In roTextureManager's example I saw it to be used for pkg:/ images that is why I asked.

Just be aware that using CreateObject("roBitmap") does not count against the roTextureManager's LRU management, so if you're loading bitmaps outside of the roTextureManager, then you could very easily overrun the memory. It's also worth noting that roTextureManager isn't aware of you keeping bitmap references alive, so its LRU management may unload a bitmap from its own cache, and think that memory is available to it again, even though it isn't. I believe the general rule of thumb I was told was to keep bitmap references that aren't fully managed by roTextureManager down to under 5mb.

[scorpiontahir02]

"TheEndless" wrote:

Just be aware that using CreateObject("roBitmap") does not count against the roTextureManager's LRU management, so if you're loading bitmaps outside of the roTextureManager, then you could very easily overrun the memory. It's also worth noting that roTextureManager isn't aware of you keeping bitmap references alive, so its LRU management may unload a bitmap from its own cache, and think that memory is available to it again, even though it isn't. I believe the general rule of thumb I was told was to keep bitmap references that aren't fully managed by roTextureManager down to under 5mb.

I have tried to look for roTextureManager behaviour using r2d2_bitmaps, what i have seen is that images pulled by roTextureManager does not take space in bitmaps memory until we load bitmap by callingmsg.GetBitmap() and keep a reference to it. So as far as i know roTextureManager takes only that much space which we know of as we have references to those bitmaps. So either we are creating bitmaps with CreateObject or msg.GetBitmap it shouldn't make a difference as we know what total memory is consumed by bitmaps created by both the requests. Although I don't know where roTextureManager stores images (not bitmaps but files) which it downloads. But it surely is not bitmap memory otherwise it would have shown using r2d2_bitmaps. Am I getting roTextureManager wrong here?

[TheEndless]

"scorpiontahir02" wrote:

"TheEndless" wrote:

Just be aware that using CreateObject("roBitmap") does not count against the roTextureManager's LRU management, so if you're loading bitmaps outside of the roTextureManager, then you could very easily overrun the memory. It's also worth noting that roTextureManager isn't aware of you keeping bitmap references alive, so its LRU management may unload a bitmap from its own cache, and think that memory is available to it again, even though it isn't. I believe the general rule of thumb I was told was to keep bitmap references that aren't fully managed by roTextureManager down to under 5mb.

I have tried to look for roTextureManager behaviour using r2d2_bitmaps, what i have seen is that images pulled by roTextureManager does not take space in bitmaps memory until we load bitmap by callingmsg.GetBitmap() and keep a reference to it. So as far as i know roTextureManager takes only that much space which we know of as we have references to those bitmaps. So either we are creating bitmaps with CreateObject or msg.GetBitmap it shouldn't make a difference as we know what total memory is consumed by bitmaps created by both the requests.

It may or may not make a difference to consumed memory, but it does affect the roTextureManager's ability to manage its memory automatically. One of the primary benefits of the roTextureManager is its LRU cache based memory management. If you're keeping references to bitmaps open and/or loading bitmaps into memory outside of the roTextureManager, then that LRU cache functionality is hindered. This is especially important on the older Roku 2 XD/XS and the Roku Streaming Stick, as their texture memory is much more volatile. If you're only testing on a Roku 3, then you're unlikely to see any issues as it has significantly more memory to work with.

"scorpiontahir02" wrote:
Although I don't know where roTextureManager stores images (not bitmaps but files) which it downloads. But it surely is not bitmap memory otherwise it would have shown using r2d2_bitmaps. Am I getting roTextureManager wrong here?

r2d2_bitmaps will list the file location, if it's saved to a file somewhere. For example (see the path in the 6th column):

0x7d4affde  1280    720   4  3686400 /nvram/theme/HD/BackgroundBitmap.jpg
0x3161a9e    100    100   4    44800 /nvram/theme/HD/LabelListFocusBitmap.9.png
0x3ab82ce    100    100   4    44800 /nvram/theme/HD/LabelListFocusFootprintBitmap.9.png

In the case of downloaded images, it usually looks something like this:

0x7d91bbb6   210    300   4   268800 /tmp/download/ec852ebb64f01df79d7cf610c2e92e41
0x7da884c6   210    300   4   268800 /tmp/download/a3ccbd24b8abe15ecb36b655ed0e88fb
0x7d91c646   210    300   4   268800 /tmp/download/c3c31e84e9b0619b84eb1dc91b965849