Roku Developer Program

[sonnykr]

Thank you NewManLiving for sharing the code. This code is great, I tried it with my app and the same issue happens.

But I got some insight of what is going on. My images are huge, even though they are grid thumbnails and each of it is around 90kb in size (1050 X 590). It starts failing exactly after 16 successful requests.

I tried the same code with smaller images of 43kb (460 X 360) and it passed! All requests passed successfully.

So I think my assets are going over limit (in terms of dimension - width and height of images) what texture Manager can handle. Any thoughts?

[NewManLiving]

Your probably running out of memory my friend

Open up a telnet session at the box ip and port
Issue the command r2d2_bitmaps. The first time
The command will fail. The second + times will
Allow you to see how much memory your
Images are using.

[NewManLiving]

Port is 8080 for me

[sonnykr]

r2d2_bitmaps says:

Available memory 114048 used 69885952 max 70000000

Does that mean out of max 70000000 bytes, the app already used 69885952 ?

[NewManLiving]

Yes it does. And if you plan on supporting
The 2 boxes then you have even less, a little more than
Half the memory if the 3 box. 38 or 39 depending
On the firmware. You did indeed run out of memory
Read the documentation on roBitmap for some
Further insight

[NewManLiving]

One other thing you should be aware that a 200 * 200 bitmap is just that in memory, regardless of the type and size of the file. For example a png might be larger
than a jpg but since they are both 200 * 200 they occupy the same amount of memory. The smaller file size is important only for downloading. As far as ROKU memory is concerned there is no difference. You can use roURLTransfer to write your images to disk and open and discard as the user moves along. You can also do this with
the texturemanager by creating what I call a cache cloud. It appears to have some sort of LRU so the next loading is faster. You just load and unload as you go along
However, in my opinion, Program design within the modest limitations of ROKU memory constraints is the primary issue. Would be nice if it had the same memory as
Apple TV or even the new Fire TV. Been dabbling with that as well. Got my eclipse set up for both environments. But Fire TV has its pitfalls as well. Android based
girds are clunky. Bloated Java Code with a ton of packages just to say 'Hello World". Really like the ROKU the best for development. Just does not have it in the memory department

[sonnykr]

Ok, I think you can help me in this issue:

I have a series of screens with grid populated through texturemanager. When I load the main (home) page:
Available memory 26452096 used 23547904 max 50000000

Once I go from the main page, there is another page with grid generated similarly.
At this point of time; r2d2_bitmaps says:
Available memory 6111360 used 43888640 max 50000000
and is understanable.

But once I navigate back to the main page, i am disposing all the bitmaps to free up the memory.

function dispose() as   
    m.manager.CleanUp()
    m.requestList.Clear()
    
    m.ListCount = 0
    m.sendCount = 0
    m.receiveCount = 0   
end function

but still r2d2_bitmaps says:
Available memory 6111360 used 43888640 max 50000000

Which actually means that, bitmaps remain in the memory. and eventually app goes out of memory and crahses.
How to deal with this?

[NewManLiving]

All bitmap variables that were assigned to any list
Must be set to invalid. All held texture requests
Must be set to invalid

Not home right now but the idea is

For each texture in texturelist
Texture.bitmap = invalid
Texture.TRequest = invalid
End for

All and every held reference must be set
To invalid like any other object before memory
Is released

If you look at your telnet list
You can see the bitmaps that are still
In memory. They are the same size as
Your images with 3 extra bytes. May be 4
Don't really look at those extra bytes much
When you don't see them in the
List anymore then they
Are all released. There is one exception
Which occurs when bitmaps are released
And swapbuffers or finish is not called
Then you may notice hanging bitmaps

People on here worked without r2d2_bitmaps
For years. I would have packed it away
If I had to keep guessing or constantly
Measuring.

[sonnykr]

viewtopic.php?f=34&t=71353

[EnTerr]

"sonnykr" wrote:
Ok, I think you can help me in this issue: I have a series of screens with grid populated through texturemanager. When I load the main (home) page:
Available memory 26452096 used 23547904 max 50000000

Once I go from the main page, there is another page with grid generated similarly. At this point of time; r2d2_bitmaps says:
Available memory 6111360 used 43888640 max 50000000
and is understanable.

But once I navigate back to the main page, i am disposing all the bitmaps to free up the memory. ... but still r2d2_bitmaps says:
Available memory 6111360 used 43888640 max 50000000
...eventually app goes out of memory and crahses. How to deal with this?

I saw you opened new topic but answering here, since there you don't mention using roGridScreen; here you do and i think it might be important. Are you getting rid of the roGridScreen before returning to main menu or is it lingering still in some variable/global?

I seem to remember roGridScreen is a very special beast with special treatment for video memory and "damaging" some underlying screens (or was it the other way around. don't think was documented but can be found on the forum). My impression is it is a greedy beast and having >1 grid screen in existence is looking for trouble.