Roku Developer Program

[destruk]

For small menus with fewer than 5 highlighted options, it's really fast to draw everything and then use swaplayers() to switch between selections.
For screens with much more variation this isn't very practical. What I'm seeing is it takes 2 or 3 seconds to redraw the full screen with the updated graphics and text to display.
What's worse is if the roku is busy drawing stuff, then it misses the Home button on the remote if the wait(X,port) interval is set too small. ie
Wait(100,port) with redrawing the screen every six 'invalid' timeout intervals makes the box unresponsive to the remote at all requiring a reboot.

Besides switching between roimagecanvas to display the video, and roscreen to display what I need there, are there any possibilities I'm missing for roImageCanvas to be faster?

[RokuJoel]

There's some discussion from a few years ago about splitting your image up into separate sections with SourceRect and drawing each section to a different layer with targetRect, apparently this technique is much faster for painting the full screen.

Also, theoretically, you should be able to run roscreen on top of a playing video, probably need to create the screen in the same function and run it on the same port as your video player or video screen. That might be faster.

One thing i've noticed - if you pump updates into roImageCanvas, it starts to speed up after a bit.

- Joel

[TheEndless]

Why not use roScreen for everything? It's much faster all around. Depending on your video resolution/bitrate, you could potentially run into some video memory issues, but if all of your video is 720p or below, you should be good (make sure to call SetMaxVideoDecodeResolution(1280, 720)).

If you're married to the roImageCanvas, then this old thread provides some optimization techniques.. viewtopic.php?f=34&t=30944&p=188970#p188970

[destruk]

I guess I was confused by this -
Once an roScreen is created, the display stack enters “Game Mode”, and other screen components documented in the Component Reference cannot be used. Other screen components cannot be intermixed with roScreens as the roScreen display stack is maintained independently from the main screen component display stack. When the final roScreen component is closed, other screen components can be used again.

Is there a list of 'screen components'? Has anyone done testing with roAudioPlayer mixes with an roScreen to see if the same graphical bugs crop up when using audioplayer with a gridscreen?

[TheEndless]

"destruk" wrote:
I guess I was confused by this -
Once an roScreen is created, the display stack enters “Game Mode”, and other screen components documented in the Component Reference cannot be used. Other screen components cannot be intermixed with roScreens as the roScreen display stack is maintained independently from the main screen component display stack. When the final roScreen component is closed, other screen components can be used again.

Is there a list of 'screen components'? Has anyone done testing with roAudioPlayer mixes with an roScreen to see if the same graphical bugs crop up when using audioplayer with a gridscreen?

I'm pretty sure "screen components" is referring to all of the roXXXXScreen components, and that statement means that you can't display any other screens on top of your roScreen until/unless you invalidate it. The roVideoPlayer isn't a screen itself, so it and the roScreen can be used together.

As for using the roAudioPlayer component with the roScreen, the "Full CD Listening Party" sub-app inside of the AOL HD channel uses an roScreen and an roAudioPlayer together without issue.

[destruk]

Thanks again