Roku Developer Program

[Komag]

on roScreen it's roRegion

[lokma]

I have recently began developing a custom UI for my channel and have been using the roImageCanvas so far, and it has been working relatively well so far. My screens are mainly redesigned roListScreens with a couple more features. I have scrolling, some UI changes depending on the item focused and it seems relatively smooth so far.

However, reading this topic I have seen that most of you say that the roScreen is faster. How come? It was my understanding(backed by a little experience I've had with it while building this channel) that when updating the roScreen, I would have to redraw the whole screen, no matter the volume of the changes which occurred. Meanwhile, on the roImageCanvas, I just update the item and call setLayer again, and that's it. Is there something I've missed in the way the roScreen works?

If someone could explain in a bit more detail why and how roScreen is faster than roImageCanvas, I would be very thankful. Any way of improving the performance of my channel is welcome.

[NewManLiving]

roScreen uses the 2D API and depending on the device may have access to OpenGL. It can also be double buffered for top performance. The imagecanvas is a much higher level component with a simple interface. Simple interfaces generally involve multiple layers and not direct access. As far as drawing everything over you can use the composite/sprite feature of the 2D to emulate the layers of the inagecanvas. I have seen some pretty impressive work done with imagecanvas so if your happy with the results then stay with it. However, if you are the creative type you will eventually be led to use roScreen. It offers the best there is for those of us who do not have access to NDK.

[NewManLiving]

Sorry hit the submit by mistake. finally, imagecanvas is just that- a canvas designed for images and not optimized for animation. The 2d is designed for animation- a menu is an animation

[RokuMarkn]

When you change an item in an ImageCanvas, it redraws the whole screen, just like when you change something on an roScreen. The only difference is the redraw is done by the firmware in the case of the ImageCanvas, whereas it's done in your Brightscript code in the case of roScreen. So although the Brightscript code looks simpler, the actual work being done is approximately the same. roScreen gives you more direct control over what's being drawn and the timing of the changes.

--Mark

[NewManLiving]

Well I think a can perceive a slight performance increase if I really watch for it. But it may be my imagination 😄

[EnTerr]

"RokuMarkn" wrote:
When you change an item in an ImageCanvas, it redraws the whole screen, just like when you change something on an roScreen. The only difference is the redraw is done by the firmware in the case of the ImageCanvas, whereas it's done in your Brightscript code in the case of roScreen. So although the Brightscript code looks simpler, the actual work being done is approximately the same. roScreen gives you more direct control over what's being drawn and the timing of the changes.

So "if the shoe fits" roImageCanvas API, there will be no significant difference in speed comparatively to re-doing it with roScreen? Regardless if the player is OpenGL or DIrectFB?

"NewManLiving" wrote:
roScreen uses the 2D API and depending on the device may have access to OpenGL. It can also be double buffered for top performance. The imagecanvas is a much higher level component with a simple interface. [...] finally, imagecanvas is just that- a canvas designed for images and not optimized for animation. The 2d is designed for animation- a menu is an animation

Some clarifications, to avoid confusion:

• roScreen does not "use", rather it "is part of" the 2D API, the "DIY-drawing" model


• There is no reason to believe roImageCanvas does not take advantage of OpenGL (actually i'd appreciate hearing from the Co on that)


• double-buffering does not improve performance - its purpose is to eliminate flicker. Image canvas likely does the same (does it flicker?)


• the 2D API is "designed for animation" only in the sense that one can be "close to the metal" when doing say tweens or transitions, e.g. by doing it frame-by-frame. Same can be done in roImageCanvas - by time, without being sure how it really looks on screen due to async update. Then again with roScreen there is some of this uncertainty too, because of how SwapBuffers() may - or may not - wait for VSYNC, depending. So it's a mixed bag.


• UI elements like menus are not proper animations - i mean you may flourish them with animations but that's decoration.

That aside, i agree with the spirit of what you said.

(*) by shoe-fit i mean the use pattern matches the canvas conceptual model, layers of images/text. And i guess ifImageCanvas.allowUpdates(bool) can be used to provide transactionality of an update, akin to Finish()/SwapBuffers() ?

[NewManLiving]

You read too much into things my friend. For example; roScreen supports the ifDraw2D interface which makes it just the same as any other component that is designed to use the 2d interface. It does not make it part of the 2D anymore than roBitmap is. I don't need to go any further than this

[NewManLiving]

Whoops don't want to get I trouble here. So let's change the word support to implements whewwwww 😐

[lokma]

Thank you NewManLiving and RokuMarkn for the detailed explanations. Judging by what I've heard, for now I can stick to the roImageCanvas as both the performance and the code complexity are satisfying...for now 😄 But it's good to know that I have a backup plan if roImageCanvas fails me 🙂

@EnTerr So far I haven't experienced flickers with the roImageCanvas, the transitions, even when changing focus while scrolling, seem pretty fluid...