Roku Developer Program

[NewManLiving]

I would love to discuss this at some point, but today I am working. But briefly, there is no mystery behind it. As I stated I am developing an application that uses animation (in the sense of special effects). My channel has six modules that encompass audio, video and a reader. The main menu (itself a module ) creates and keeps a list of module objects. Each object is self contained and manages its own compositor, components, bitmaps, animations, and event loops. All global objects are in the channel object that each module references upon creation. The central cache manager is also in the global object. As the user navigates the menu, module objects are created and layered on top of the previous layer (compositor) or, in the case of memory constraints, are destroyed and then recreated by the menu manager. Composites can be layered one on top of the other or you can destroy and re-create the module. It is modular in respect that the compositor is itself a container class and allows me to "Contain" the contents of each part of my program without having to clear the screen and keep some sort of complex , self-built container class to manage complex redrawing and layering. It has the added advantage of drawing all its Sprites internally with one call (even DrawAll is fast), It allows me to hide/show/layer any sprite with one function call and then manages the redrawing. It can even animate a series of regions for me. The compositor does not manage memory for you. It holds on to the bitmap/sprite until you release it. My mild frustration (and it is mild - I have great respect for you) is your (and a couple of others) implication that is for the most part useless. Granted, it may not be for everything, but for modular application development it saves me a great deal of time, the extra code is worth the containment and the added speed advantages. I have tried the other approach and the more complex my application became, the more tedious became the management of it. The same goes for regions, I think I have demonstrated adequately that using what is already there is a lot better than dragging a bunch of bitmaps across the screen. Other than that there is not much more to say. Even with the compositor you still have to manage memory and perhaps even more so if your application is "screen" centered, or where the background takes a prominent role. In my video module I use a grid and some menus, I also use semi-transparent lists that display over the video to allow the user to select different options or save video references. There is animation, exploding/fading menus and -There is still plenty of memory left. Anyway lunch is over, but that is it in a nutshell. I don't know what more I can tell you. The point is that while it may not be for everything, It is a very useful component for many applications, not just a few

[NewManLiving]

One additional thing (i'm also a nurse so I have to sneak into the bathroom for this), If I had to do what I believe you are describing (which would increase memory as the compositor is holding onto the bitmap as well ) I would investigate (and I have already begun to do so for another reason) the ability of the compositor to drawto a bitmap. At a first glance, this seems to me a plausible way to coexist between writing to the screen and using a compositor for the advantage of speed and containment.
Obviously a compositor setdraw to screen essentially puts the screen in a non-dominant state and lets the compositor do its thing. However you may be able to do the reverse and leave the screen as the dominant factor and simply create smaller compositors that contain a series of animation/regions/bitmaps and draw this onto the screen, dump the buffer and then disappear freeing memory. Much like the virtual buffer. Obviously I will at some point investigate this got to go

[TheEndless]

"NewManLiving" wrote:
My mild frustration (and it is mild - I have great respect for you) is your (and a couple of others) implication that is for the most part useless.

I didn't mean to come across like that. I don't think it's useless at all. I've just struggled to find a viable way to use it when my UIs require some of the effects I referred to above (primarily text and fades). And as I stated, my framework allows me to very easily manage the placement and animation of objects on screen without having to do any complex tracking. The way I've implemented that may be a very worthwhile conversation for us to have at some point, as, if I understand you correctly, it'd likely benefit your implementation as well.

"NewManLiving" wrote:
Even with the compositor you still have to manage memory and perhaps even more so if your application is "screen" centered, or where the background takes a prominent role. In my video module I use a grid and some menus, I also use semi-transparent lists that display over the video to allow the user to select different options or save video references. There is animation, exploding/fading menus and -There is still plenty of memory left.

I believe you mentioned before that you're developing on a Roku 3. If that's the case, exclusively, that could very well explain our disconnect here. The Roku 3 will take just about anything you can throw at it without issue, but try running the same code on a Roku 2 (current or previous generation, though current generation seems a lot more sluggish) and you may be surprised. If you haven't tried that, I'd encourage you to do so, and the source of my apprehension may become much more evident, particularly when video is involved. For example, on my Roku 2 XD, if I load two screens worth bitmaps (e.g., background image, 15 posters, overhang, and miscellaneous icons) into memory while video is playing, things quickly become unpredictable and painfully sluggish, so using up additional memory creating bitmaps for use as sprites instead of drawing directly to the screen makes me nervous.

In an ideal world, I could limit my 2D based channels to the Roku 3 platform, but that's not a realistic option, so I have to ensure the UI works and is responsive on multiple platforms. I test everything on at least four different Roku platforms (Roku 3, Roku 2 (current gen), Roku 2 XD, Roku LT (previous gen), and an original first gen Roku, if necessary), and the result can vary wildly. As I said, though, your passion for it has intrigued me enough to investigate the compositor further this weekend. I'm very curious, memory management aside, to see if the lower end platforms will show a performance boost using it.

[NewManLiving]

My apologies. I do develop on ROKU 3 and have no intention of developing otherwise, (I usually put that at the top of my examples) since this is a hobby. In my opinion there are too many ROKU boxes out there to support them all unless you do it for a living. My brother bought a 2x by mistake so I may set that up to see what differences there are. Hey I'm 60 years old, started out programming in my twenties when everything was scarce, slow and limited, and you had to use your imagination and program in several languages esp assembler and C to write routines for speed. Learned OO from SmallTalk and eventually wrote mostly in C++, PowerBuilder, Visual Basic and Flash. When the DOT coms went under I took up nursing. Last year I Bought a ROKU 3 to break away from cable and discovered it had an API --- so here I am. Anyway I always like a challenge and so far everything I had envisioned (my components) I pulled off to my own satisfaction at least, if the ROKU 2x has the same problems you have described I may be interested. I am very curious to see if reverse engineering my compositor theory would work. But most of all I thank my Lord Jesus that I still have a good mind and a great imagination. Back to work