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.
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.
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
“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.
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
“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…
“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?
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
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
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 ?
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
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
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
You guys might agree more than you think and just be accidentally talking past each other here 
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.
“Komag” wrote:
You guys might agree more than you think and just be accidentally talking past each other here
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]
[upload|bSN+kkongcNkKZxFV3CCMg==]
[/spoiler:2bszjmg0]
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
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
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
