Roku Developer Program

[NewManLiving]

Well specifically this concerns grid development as close
As possible to the built-in grid, using the texturemanager
In my experience I do not believe it is possible to do this
Without that jarring effect, esp on lower-end devices unless
One uses every optimization technique available. The best I have
Found is what I previously stated and have produced a decent grid built upon it.
So, Preference really has little to do with it. You experiment
And use what works the best based upon the standards you set
For yourself.

[NewManLiving]

One has to wonder though how you came to that conclusion. I don't believe that you even took the time to consider my reasoning (and proof) . For example,
You have a grid (If you have ever significantly developed one) that uses the texturemanager to request bitmaps as the user scrolls the grid.
What do you do as they very quickly arrive in mass?

A: loop through a 2d array of bitmaps and frantically redraw all your rows and columns on the screen a gazillion times as you are at the same time easing in rows which obviously changes all the x, y coordinates of the bitmaps coming in. So now what do you do ? You have to somehow let the texture receiver know that your bitmap x,y coordinates are changing rapidly during your ease to avoid having the wrong ones pop into the placeholders creating
a big mess. And-- at the same time constantly checking the texture queue because if you don't remove them right away you face other problems. So now you really begin to studddddderrrrrr as the manager is bogging down your whole system and you are taxing the processor with drawobject assults. I could go on and on.

[NewManLiving]

Sorry hit the sumbit by accident

Obviously you have to avoid that scenario which occurs when you simply draw bitmaps to the screen. It does not take much to figure that one out.
Solution B: Your compositor draws all sprites with one call. Your region offsetting leaves the bitmap coordinates static. The new row is drawn in the virtual portion of the bitmap and also eased in via region offset so you only have to update your x,y coordinates ONE TIME no matter how long your ease takes. With that kind of optimization your texture receiver can quickly update any cell in any grid or multiple grids very quickly.

So my friend you should not (as you have in the past) so easily dismiss something you have not even tried or tested yourself. You may discourage others from taking full advantage of the API

[TheEndless]

"NewManLiving" wrote:
One has to wonder though how you came to that conclusion. I don't believe that you even took the time to consider my reasoning (and proof) . For example,
You have a grid (If you have ever significantly developed one) that uses the texturemanager to request bitmaps as the user scrolls the grid.
What do you do as they very quickly arrive in mass?

A: loop through a 2d array of bitmaps and frantically redraw all your rows and columns on the screen a gazillion times as you are at the same time easing in rows which obviously changes all the x, y coordinates of the bitmaps coming in. So now what do you do ? You have to somehow let the texture receiver know that your bitmap x,y coordinates are changing rapidly during your ease to avoid having the wrong ones pop into the placeholders creating
a big mess. And-- at the same time constantly checking the texture queue because if you don't remove them right away you face other problems. So now you really begin to studddddderrrrrr as the manager is bogging down your whole system and you are taxing the processor with drawobject assults. I could go on and on.

I can't speak for RokuMarkn, but I recently developed a grid based 2D channel (not a traditional poster grid), and it was a dog. I switched to the compositor based on your earlier enthusiasm for it, and found it offered no improvement in rendering time. I even did some extensive benchmarks to see if it was my sprite generation code or the just how it was, and got the same results... no speed improvements. While it's certainly easier to move a sprite and call UpdateAll() in the draw loop, I found it much more complicated to create the sprites in the first place for anything more complicated than a simple bitmap. It also requires creating bitmaps for text, which is additional memory overhead, as well as creating new bitmaps for scaled images (it'd be nice if they added scaling functionality to sprites). Either way, I think the lack of any noticeable speed improvements is where the "matter of preference" comes in. Early on it was suggested that the compositor should be faster, because compositing was done by the hardware, but I don't think that's the case, or if it is, it doesn't seem to offer any performance benefits.

[NewManLiving]

I do not create or move any sprites. My grid is the only sprite. One large sprite. When the user scrolls I draw the new row into the hidden virtual buffer and then its all region offsetting from there. The compositor is used as a convenient way of drawing the grid along with accessory sprites such as a selector. If I understand you correctly then you are creating multiple cell sprites and offsetting each of them. This obviously would not offer a speed improvement since you are essentially doing the same thing as bitmap offsetting. I have a poster type grid which is not a dog. At least not on the devices I have tested it on. I also have developed grids for other people that are being used and they function quite well, although not as complex as my poster grid. When I get a chance I'll publish privately what I have of a project i'm currently working on that includes the grid and you can see for yourself. If you ever loaded my example that I refer to on here you can get an idea of how it functions. The only difference is that I use the texturemanager to get the bitmaps. The speed and response time of the drawing has not changed a bit. The only modifications I had to make to allow for the slower boxes was to cancel request the textures if the user began to scroll away before all bitmaps are received and drawn. Even this was not a big deal just a very slight irregular movement. But my aim was fluidity across the board. The home screens have far more jarring as the manager kicks in than my own without the modification.

As far as text that is also drawn only once. As to memory, my framework knows how to unload non-essential sprites and recreate them. I very seldom use more than 10mb at one time no matter how many bitmaps I need to show the user. I just adjust the memory cache portion of my grids and they load and unload as instructed

I also use the screen to do large fades and transitions by hiding sprites or just simply calling compositor.DrawAll, then draw to the screen , then call swapbuffers. I took your advice on that and I'm glad I did.

So I am really not clear about your implementation. It does not sound the same nor produce the same results as my own. I would have to see it

[TheEndless]

"NewManLiving" wrote:
I do not create or move any sprites. My grid is the only sprite. One large sprite. When the user scrolls I draw the new row into the hidden virtual buffer and then its all region offsetting from there.

Well that's certainly a key distinction. I assumed you were using the compositor and indvidual sprites to represent each poster. I hadn't really considered using it the way you are, as it seemed logical that each poster would be a separate sprite. Interesting...

"NewManLiving" wrote:
I have a poster type grid which is not a dog.

In my case, it's not posters, but lots of text and updating progress bars with video playing on the same screen. It's not a traditional grid, but a similar concept. The video decoding in the background is the primary culprit, as that eats up a ton of CPU cycles. The "dogged-ness" of the grid is really only apparent on the low end Rokus, and is greatly mitigated by stopping the video. It runs pretty smoothly on the Roku 3, Roku TV, and streaming stick even with video playing. There are also a lot of web requests and processing go on "in the background"... I *really* wish Roku would give us a background worker thread to do stuff like that...

"NewManLiving" wrote:
As far as text that is also drawn only once.

In my case, the text is updating regularly, which also has a noticeable effect. I also draw it to a transparent bitmap to workaround the anti-aliasing bug with DrawText.

"NewManLiving" wrote:
As to memory, my framework knows how to unload non-essential sprites and recreate them.

I have the same, but as I'm having to create in-memory bitmaps for the text and the individual sprites, I'm using up almost twice as much memory as I would if I were to draw directly to the screen. And as mentioned above, I have video running in a window at the same time, which greatly reduces the memory available to me.

I have since come up with what I think is a really clever way to address all of the issues above, but it's a significant undertaking that I don't have the time for at the moment. Once I do, I'm excited to try it out...

[Komag]

"TheEndless" wrote:
I have since come up with what I think is a really clever way to address all of the issues above, but it's a significant undertaking that I don't have the time for at the moment. Once I do, I'm excited to try it out...

What a tease! Do you think your new concept might apply to game performance as well?

[NewManLiving]

Well I'm glad we are at least on the same page. And I am guilty of over emphasizing the compositor. The only reason I started using the compositor was to draw complex backgrounds. As my interface became more rich I found myself constantly redrawing the entire screen even for the slightest change. Being that the back buffer is indeterminate after swapbuffers is called there is no telling what will show up unless the entire screen is redrawn. With the grid for example
Calling SwapBuffers after you draw the cell would leave me with a black screen with only the new cell showing. So of course in the case of a texture managed grid there is a tremendous amount of updating going on so everything else needs redrawing as well. Without the compositor I would have this additional overhead as well. Even more so with a theme based background which has more graphics

[RokuMarkn]

Geez, NML, no need to get so worked up about this. First, I was addressing the compositor, not the texture manager. I agree that the texture manager is useful for managing remote images. As I said, I haven't done any measurements; I'm basing my comments about performance on my understanding of how things are implemented. It's true that without the compositor you have to redraw the entire screen. But if you use the compositor, then the firmware has to redraw every screen. You're not saving any work, you're just moving it from Brightscript to the firmware. The firmware might be able to do this very slightly faster but I wouldn't expect it to be significant. TheEndless' measurements agree with my expectations. You mentioned that you have presented "proof" -- I don't see what you're referring to. If you have some measurements that support the idea that the compositor is faster, would you please present them again?

--Mark

[coredump]

NewManLiving what would be the best way to download bitmaps in your example ?

In the Function :

GetVCBitmaps(number As Integer, row As String, width As Integer, height As Integer)

Would I use TextureManager, GetFileAsync or something completely different ?