Roku Developer Program

[squirreltown]

UnloadBitmap(url as String) as Void

three questions:

The URL here should be the (for instance) tmp: directory where the bitmap was created from, correct?

Does this remove the bitmap completely from memory? ( I suspect not)

If not, how to do that? Having trouble with a roScreen that downloads and rotates bitmaps, it eventually causes the screen to crash, sometimes the box reboots, no message in the debugger ever.

Thanks

[RokuJoel]

You would need to remove it from any variable that was referencing it first, for example:

array=[bitmap]
region=createobject("roRegion",array[0],0,0,array[0].getwidth(),array[0].getheight())
array2=[region]
sprite=compositor.newsprite(0,0,array2[0])

Then you would have to, in reverse order:

sprite.remove()
array2[0]=invalid
region=invalid
array[0]=invalid
bitmap=invalid
texturemanager.unloadBitmap("http://myserver.com/bitmap.jpg")
screen.swapbuffers() 'graphics memory is actually released here

[squirreltown]

Thanks Joel, thats quite an operation. I guess the sticking point for me is that even though the bitmaps in question are not in an array or part of a compositor batch, the region is still being used - its just one overall screen region that all bitmaps fly around in- so I cant invalidate it without stopping everything. Should I make each bitmap a separate region as it gets loaded just so i can dump it later? I currently have no other use for regions - it loads a bit map and flys it across the screen for while - very simple.

[RokuJoel]

I'm not sure why you would want to invalidate the bitmap that you draw everything to.

You might however want to invalidate a bitmap that has moved off the screen and is no longer needed, and if you aren't using it for anything, make sure all references to it are invalid and then call ifTextureManager.unloadBitmap

If it still isn't unloading, maybe you need to runGargbageCollector() ?

- Joel

[squirreltown]

Thanks for the reply Joel. I'm just trying to diagnose something that doesn't show up in the debugger as a problem. I have 10 variables representing bitmaps. At a certain interval new files are downloaded and each of those variables are reassigned to newly created bitmaps and the old bitmaps are unloaded with unloadBitmap. This should be able to repeat forever if the old bitmaps are actually getting released from memory but it only works for a few hours so lack of memory is the most obvious suspect correct?

Could you clarify two things-
"I'm not sure why you would want to invalidate the bitmap that you draw everything to. "
I don't understand this. I thought I was drawing bitmaps into a region, not drawing something into a bitmap. As i said I can't invalidate the region -there is only one.

"You might however want to invalidate a bitmap that has moved off the screen and is no longer needed"
I do need to get rid of old bitmaps but am using the same variable name just reassigning it to a new bitmap. Is this not what unloadbitmap does? I have a variable thispic0. when thispic0 is assigned to a new bitmap through the texturemanager, the old bitmap should be disposed of by unloadbitmap. The docs only say its removed from the texturemanager, they don't explicitly say its removed from memory - this is what I'm trying to track down, I'm still just guessing at the actual cause of my crashing.

runGargbageCollector() doesn't look like its asynchronous according to the docs, am I wrong about this?

Thanks

[RokuJoel]

If I understand correctly, you are just taking an existing variable representing a bitmap and using it in a new CreateObject statement without invalidating it and then releasing it first, I think you need to invalidate it and call release before you reuse the variable for a new bitmap object. This may be some kind of bug in our system, since the reference should go away when you invalidate it. Which firmware version are you using?

A region is just a reference to a bitmap or a subset of a bitmap. The screen itself is essentially just another bitmap and behaves as such, for example, screen.getwidth() works just like bitmap.getwidth(). You should be able to create a bitmap and then use drawobject or any other calls, to the bitmap just as you would to the screen. You can even point a compositor at a bitmap instead of the screen and have it do all its work on that bitmap, and then draw it to the screen.


If a bitmap was 1000 x 1000 px, you could create a region from that bitmap:

region=createobject("roRegion",bitmap,100,100,100,100) 

and you could draw to that region:

region.drawobject(10,10,another_bitmap)
region.finish()

whatever you draw should appear at 110,110 on the 1000x1000 bitmap

In your example with thispic0, you should first make thispic0 invalid before assigning it a new bitmap. You might even want to wait until you've called finish or swapbuffers and then unload the old bitmap and assign the new one, you might try both ways and see if one works better than the other.

RunGarbageCollector is not an asynchronous command, it usually (but not always) runs fast enough to be used within graphical applications. It really shouldn't be necessary to use it in the context you are working in.

- Joel

That

[squirreltown]

Thank you Joel, you understand it correctly. I will do it that way and see how it works.
Thank you for the region/bitmap explanation that was very helpful.

[TheEndless]

Hey squirreltown, as a side note, the roTextureRequest will take a remote URL, so you shouldn't need to download the bitmaps to the local tmp:/ folder anymore, unless you have a need for them to be there. Should save you a bit of extra code there...

[NewManLiving]

Regions are portals into a bitmap. For example; if you are on a mountain and outside the cabin is a large expanse of God's creation all around you. You go inside the cabin and look out a window and you can see only what the window allows you to based upon its size and where the window is. The landscape outside is the large bitmap, the window is the region that looks into the bitmap but only according to its size and position. If you move to different windows in the cabin with different sizes you would see more/less of different parts of the same landscape. This would be like creating different regions at different locations within the bitmap.
If you could pick up a window with both hands and move it up, down, left or right, this is like offsetting the region at x, y coordinates and you would see adjoining parts of the landscape outside. If you could stretch the widow bigger or smaller this would be like offsetting the region's width and height.

Using a sprite allows you to put that region or window wherever you wanted inside the cabin and unlike a window, still see the same landscape that it was originally looking at in another part of the cabin. Layering sprites allows you to put one window on top of the other

If you would take the time to discover the 2d api. In a short time you will create interface that is every bit as impressive if not more so than the ROKU home screens
When I first started with it I was somewhat intimidated. But now, just a few months later, I have produced all kinds of grids, menus, and various interface with special effects that are only limited by my imagination. I am just currently finishing up virtual versions of these components which allow me to load large amounts of data with modest memory impact. You have complete control over just about everything.

As a matter of fact, a very basic non-virtual version of the ROKU home screen is really quite simple. It takes far less code than you would imagine. A couple of bitmaps one for the list menu and one for the grid. Each bitmap having a region that defines what the user sees. The regions would have their setwrap to true so all the scrolling is handled for you. You wrap the two regions in a sprite, this allows you to put the menu and the grid at any position on the screen that you desire. In your event handler just move the offsets of the regions - or + to scroll the regions. You can feel free to use drawing functions all you want to update your bitmaps. You can even be liberal with drawtext since you are not writing a game but application interface so generally you will have nothing going on while you are drawtexting

[squirreltown]

TheEndless - thank you for that, I noticed that in Joel's post and will make that change. I really like getting rid of code and making things simpler.

NewManLiving - thank you for that great description, I know I'm going to refer back to it often. Thats the first good description of a sprite I've encountered, I finally know what one is, you probably cant imagine how much I learned from that.

I know you are right about the 2d thing. I have built one 2d project which was the example in this thread - a screensaver with a settings page thats also 2d with a simple menu. I know its the only way to get things to look the way i want but frankly until quite recently didn't have the knowledge to even begin, but that is slowly changing. The task of building everything from scratch is just daunting - I have one serious channel i care about - but will need to build a slideshow, the UI, all kinds of menus to replace the message dialogs, my own grid screen (not looking forward to that) and will need to design how all this will look first - Something I haven't even bothered thinking about since it was not possible for me, at least thats a fun part. I'm not a programmer but I've worked on some pretty long-term projects and the Roku has turned out to be just the same - you think you're going to build something and then it will be done, but the first time really only ends up being practice for the second time you build it, or (shudders) the third.