Roku Developer Program

[NewManLiving]

No one is getting worked up. It's just frustrating to have to keep explaining and clarifying myself For over a year now. All indications point to the fact that no one including you, took a serious look at the grid I posted here months ago. Even a cursory look indicates that I'm not creating a ton of sprites and Offsetting them. As for proof it is the grid itself. Even the old one keeps drawing to a minimum and uses region Offsetting. The new one is even more optimized.
The whole point of this thread was the best method for creating a texture managed poster style grid. TheEndless tests were based upon the assumption that I was creating numerous sprites. Offsetting sprites is the same as Offsetting bitmaps. You would be right back to square one again. What else can I assume other than you did not look at the original code, you did not thoroughly read the posts and you did not take Into consideration that TheEndless tests were based upon the wrong assumption of what I was doing. Even he said so
Perhaps it would have been better to push region offsetting as opposed to pushing the compositor. That was my own fault
As I responded earlier the compositor is useful for redrawing the entire screen especially during the time that numerous bitmaps are arriving. This puts the greatest drag on the system and depending on your method you may find yourself hammering away at keeping the display up to date
The smoothness of my grid after attempting to do it via coordinate offsetting as opposed to region offsetting is proof enough of the optimal method. I don't need benchmarks

[RokuMarkn]

No, I didn't study your grid code, because it's not relevant to this discussion. The issue is not whether your particular code using the compositor performs better than some other particular code you wrote without using the compositor. There could have been bugs or other issues in the original code. I've written several examples of smooth scrolling apps without using the compositor. You keep repeating that using the compositor puts less load on the system, but I'm pretty sure that's not true. Your statement that you have to "keep hammering away to keep the display up to date" indicates to me that you still may be confused about what's happening. Whether "you" (that is, your Brightscript code), or the compositor inside the firmware, is drawing the screen doesn't change the fact that everything on the screen needs to be redrawn on every frame. Every single pixel on the display needs to be touched on every frame, and that's where the load is.

--Mark

[NewManLiving]

I'm guilty of putting too much emphasis on the compositor
It is only a small part of the whole. But it is supposed to know when a
Sprite is dirty as opposed to changing one pixel and still have to redraw
The entire screen. Even if your argument is true, it's a small true. The otherside is region offsetting as opposed to bitmap coordinate offset and redraw which you did not even mention. You can drop the compositor and still get better results with using a region Properly
The source code has everything to do with the subject as it
It incorporates the trio. And What do bugs have to do with the whole concept?
The type of grid in discussion is the most difficult one to effectively produce
Primarily due to the texturemanager. I don't believe that you have written anything
Close to it. Smooth scrolling is easy and fast using any method but not with the texture manager

The next step would be to demonstrate our technique in a poster-grid contest using the texture manager.
I already have mine

[Komag]

You guys might agree more than you think and just be accidentally talking past each other here 8-)

[coredump]

I actually have a question about NewManLiving's code sample. It sounds like the compositor is used in place of the TextureManager, so what would be the best way to download bitmaps in your function:

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

Also, Is it possible to use the compositor in conjunction with the other 2D API, I have a menu bar on the left and only want the grid functionality on part of the screen to accommodate the overhang and menu I am drawing. Does this make any sense ? I would be happy to email you my code just sow you could run it and see what I am trying to do, if necessary.

[TheEndless]

"Komag" wrote:
You guys might agree more than you think and just be accidentally talking past each other here 8-)

I, too, think this might be the case. One argument seems to be about using the compositor vs. the other about using region offsetting, which are two different aspects of the application. I think all RokuMarkn is saying is that using the roCompositor, while it may be easier in code to redraw the whole screen, doesn't really provide any significant performance improvement. I think both agree that the bulk of the performance boost comes from using region offsetting.

"NewManLiving" wrote:
But it is supposed to know when a
Sprite is dirty as opposed to changing one pixel and still have to redraw
The entire screen.

It is supposed to, per the documentation, but in my experience, I always have to call DrawAll() unless I want to get "smearing" on the screen. Also, bizarrely, calling Draw() seems to take significantly longer than calling DrawAll(), which is the opposite of what one would expect, and defeats the whole purpose behind it (unless I'm completely misunderstanding how it's supposed to work).

"NewManLiving" wrote:
All indications point to the fact that no one including you, took a serious look at the grid I posted here months ago. Even a cursory look indicates that I'm not creating a ton of sprites and Offsetting them.

To be clear, I did a deep dive into your code when you first posted it. I imagine at the time, I was more aware of how you were using the compositor, but that was a long time ago, and as I noted above, logic (especially when coupled with your enthusiasm) would suggest if you're using the compositor you'd be doing so to take advantage of the sprites, and not just to make it easier to draw the screen. Your coding style is also a lot different than mine, so something that is obvious to you, may not be so to others looking at it. My main point being, it is very much appreciated that you've shared your code, and I don't want you to be discouraged from continuing to do so!

[spoiler=For fun...:2bszjmg0][/spoiler:2bszjmg0]

[NewManLiving]

That grid example does not use the texturemanager. And the compositor does not replace the manager. The example demonstrates an important technique of region offsetting using a bitmap buffer. While it's usefulness is unnecessary when all bitmaps are preloaded. It's true strength lies in its performance during realtime and continuous loading and unloading of
Texturemanager images. As stated correctly my emphasis on compositor was overstated, however I believe it does contribute to the whole. Most importantly if you plan on realtime loading/unloading you would benefit from doing as little drawing and changing of bitmap coordinates as possible during downloading of images. Especially if your receiver is written
To update the grid. Otherwise you will have textures drawing in places they don't belong. And you will be using a great deal of drawobject calls especially with easing during the worst possible time. The only way to accomplish this is by using a region. The region moves and the bitmap is fixed. The region already knows how to scroll. It is easier to loop through all your rows and redraw them but not efficient under these circumstances On they lower end boxes

[RokuMarkn]

I'm sorry I really don't have time to pursue this discussion in detail. I had thought that NML was claiming that using the compositor gives you performance that can't be achieved without it, and I was addressing only that one point. I think everyone (even NML) agrees that that claim is not correct, so no need for further discussion on that point.

--Mark

[NewManLiving]

Yes I did overstate its benefit. For that I stand corrected. For me it still remains part of the whole since I believe that it simplifies drawing of complex interface that would otherwise need to be addressed each
Time the grid needs updating which is very often. It would be interesting to see if there are true performance gains under this type of grid
I believe there is. Notwithstanding, I also outlined and demonstrated in detail the most important optimization technique numerous times and that was not considered at all. But Im afraid that my former passion for compositor had taken control of the entire thread. This all started with my bias statement. But I opend that with all three Compositor, sprites and regions
Anyway I'm done with this for now