Performance of roScreen

Archived
1

Hello, I’m developing my first app using roScreen the ifDraw2D components, the built-in roku search screen doesn’t quite suit my needs so I’m currently designing the search screen of my app. I want this to be quick and snappy to navigate and search, I’ve designed the keyboard using a basic layout and below it, it will display results grapped asynchronously while you’re inputting. Are there any tips I can use to increase performance as right now it seems the navigation is a tad behind and I haven’t added the asynchronous search features yet. Does getting the date and time every time I draw a frame have any noticeable effect on performance?

[upload|hR4wuwjJoOjAmWsnkOPWBw==]

Strangely the episode page runs faster, I guess not having to draw the alphabet of squares improves performance..?

[upload|ZKgV7UxdmWUToHB8VprGzQ==]

Any tips or hints would be great!

Many thanks, Jordan.

2

What Roku model number are you using? Text and alpha transparency are a couple things that hurt performance a lot in general. I don’t know the impact of getting the date and time.

You might set up a test function to make a timer, get the date and time 100 or 1000 times, then print the timer results. I’ve used this approach on lots of functions to really tell me how long it’s taking for various things, and it can be eye opening at times.

3

I wouldn’t expect grabbing the time to impact performance, but it should be an easy test. Have you commented that part out to see if performance improves?

There’s nothing on that keyboard screen that I’d expect to cause any performance issues, so my guess is there’s something in your code that’s causing the problems. Are you caching and re-using the font? Initializing a font is pretty slow, so if you’re not re-using it, that could definitely be the issue.

On a side note, that’s a nice, clean layout. I like it!

4

“Komag” wrote:
What Roku model number are you using? Text and alpha transparency are a couple things that hurt performance a lot in general. I don’t know the impact of getting the date and time.

You might set up a test function to make a timer, get the date and time 100 or 1000 times, then print the timer results. I’ve used this approach on lots of functions to really tell me how long it’s taking for various things, and it can be eye opening at times.
I’m using a Roku 1 (2710) and a Now TV box (2400), the Now TV box obliterates the Roku 1 for performance, the 1 tends to be very jittery and low fps whereas the Now TV box is pretty smooth. That’s a really good idea, I’ll start testing the speed on some of my functions to see if any can be optomised, and think about adding a FPS counter to my screens too. They aren’t running slow by any measure, it all runs quite well actually, but it just feels that the default roku screen can navigate from letter to letter faster than my screen, but I guess the transparency plays a part in that… Thank you!

“TheEndless” wrote:
I wouldn’t expect grabbing the time to impact performance, but it should be an easy test. Have you commented that part out to see if performance improves?

There’s nothing on that keyboard screen that I’d expect to cause any performance issues, so my guess is there’s something in your code that’s causing the problems. Are you caching and re-using the font? Initializing a font is pretty slow, so if you’re not re-using it, that could definitely be the issue.

On a side note, that’s a nice, clean layout. I like it!
Yes I’ve tried that, but the results are negligible really, I was only concerned about the date and time as the rest of the code is pretty straight-forward and couldn’t be done in any other way, so even if some draw function does affect performance, there’s nothing I can do about that. With the date and time, I have it set up so the date & time are grabbed at startup, the offset in seconds is then used as a reference point for roTimespan which marks every frame. So at 10:04:33, it waits 27 seconds then grabs the date & time again, then again every 60 seconds from that point for accuracy. Do you think this would be faster than getting the roDateTime every frame?

Font’s are initalised on startup and sizes are allocated to an array, so I have obj.Font.Calibri.p16, which is Calibri 16pt (~22px). I’ll go through my code and move out anything that could be initalised at startup to maximize performance.

Thank you very much! It’s a redesign of my current app, I’m having an issue with roGridScreen where the focused item flickers back and forth between two items randomly and I can’t find any way to stop it, so I’m redesigning it from scratch using roScreen. A lot of work it seems! But I’m getting there…

5

“JordanT92” wrote:
They aren’t running slow by any measure, it all runs quite well actually, but it just feels that the default roku screen can navigate from letter to letter faster than my screen
FWIW, with the built-in SDK screens, the UI runs in a separate thread from the BrightScript code, so it’ll be smoother, by default, especially on slower boxes. I wouldn’t get too hung up on matching performance on the Roku 1 box. You’ll be hard pressed to get there on any of the 27XX boxes with a lot of elements on the screen. Assuming each key on the keyboard is a separate bitmap, if you cached the whole keyboard to a single bitmap first instead of drawing each key individually each frame, and only updated the highlighted key, that would likely help a lot.

“JordanT92” wrote:
Thank you very much! It’s a redesign of my current app, I’m having an issue with roGridScreen where the focused item flickers back and forth between two items randomly and I can’t find any way to stop it, so I’m redesigning it from scratch using roScreen. A lot of work it seems! But I’m getting there…
There was a bug in the 6.0 and 6.1 firmware that caused the grid screen focused index to jump around when returning to the screen. I don’t know if that’s what you were experiencing or not, but I believe it was fixed in 6.2.

6

“TheEndless” wrote:

“JordanT92” wrote:
They aren’t running slow by any measure, it all runs quite well actually, but it just feels that the default roku screen can navigate from letter to letter faster than my screen
FWIW, with the built-in SDK screens, the UI runs in a separate thread from the BrightScript code, so it’ll be smoother, by default, especially on slower boxes. I wouldn’t get too hung up on matching performance on the Roku 1 box. You’ll be hard pressed to get there on any of the 27XX boxes with a lot of elements on the screen. Assuming each key on the keyboard is a separate bitmap, if you cached the whole keyboard to a single bitmap first instead of drawing each key individually each frame, and only updated the highlighted key, that would likely help a lot.

“JordanT92” wrote:
Thank you very much! It’s a redesign of my current app, I’m having an issue with roGridScreen where the focused item flickers back and forth between two items randomly and I can’t find any way to stop it, so I’m redesigning it from scratch using roScreen. A lot of work it seems! But I’m getting there…
There was a bug in the 6.0 and 6.1 firmware that caused the grid screen focused index to jump around when returning to the screen. I don’t know if that’s what you were experiencing or not, but I believe it was fixed in 6.2.

That’s good to know! I’m surprised at how well the Now TV Box runs it to be honest, my screens will never get too crowded as I’m going for a more simplistic approach. Currently some items are drawn off screen and scroll into view later, I’ll ensure they’re only drawn when in the bounding box of the screen and I think the performance on most screens will be pretty decent then, even on the lower end boxes. For the Roku 1, i think disabling animation altogether may be the only way to go… I’m running the latest version (no choice of course) and it still happens, although this is a grid with 11,000+ item (any items out of view are set to invalid).

My next questions is… To speed things up from a data standpoint, I want my app to download a ZIP / JSON file on startup, and use that as the central database for everything, so the only time any network activity would occur is when grabbing images. The only problem is, this file is likely to be around the 20MB mark… Do you think the boxes would be alright with this if I limit playback to 720p? Or would I run out of memory? I can’t seem to find a way of getting my current memory usage…

Thank you very much TheEndless!

7

“JordanT92” wrote:
That’s good to know! I’m surprised at how well the Now TV Box runs it to be honest, my screens will never get too crowded as I’m going for a more simplistic approach. Currently some items are drawn off screen and scroll into view later, I’ll ensure they’re only drawn when in the bounding box of the screen and I think the performance on most screens will be pretty decent then, even on the lower end boxes. For the Roku 1, i think disabling animation altogether may be the only way to go… I’m running the latest version (no choice of course) and it still happens, although this is a grid with 11,000+ item (any items out of view are set to invalid).
Sorry, I was specifically referring to the keyboard screen. If every key is being drawn separately, that means you’re drawing 38 separate keys on each pass, with 38 separate calls to DrawText. If you drew the whole thing to a bitmap first, then just updated the focus rect on each frame, that would likely significantly improve performance. There’s no reason you shouldn’t be able to do animation on the Roku 1 for that screen.

“JordanT92” wrote:
My next questions is… To speed things up from a data standpoint, I want my app to download a ZIP / JSON file on startup, and use that as the central database for everything, so the only time any network activity would occur is when grabbing images. The only problem is, this file is likely to be around the 20MB mark… Do you think the boxes would be alright with this if I limit playback to 720p? Or would I run out of memory? I can’t seem to find a way of getting my current memory usage…
Yeesh.. I don’t know how that would work out for you. 20MB may be too large for tmp: storage. That should be independent of graphics and video memory, though.

8

“TheEndless” wrote:

“JordanT92” wrote:
That’s good to know! I’m surprised at how well the Now TV Box runs it to be honest, my screens will never get too crowded as I’m going for a more simplistic approach. Currently some items are drawn off screen and scroll into view later, I’ll ensure they’re only drawn when in the bounding box of the screen and I think the performance on most screens will be pretty decent then, even on the lower end boxes. For the Roku 1, i think disabling animation altogether may be the only way to go… I’m running the latest version (no choice of course) and it still happens, although this is a grid with 11,000+ item (any items out of view are set to invalid).
Sorry, I was specifically referring to the keyboard screen. If every key is being drawn separately, that means you’re drawing 38 separate keys on each pass, with 38 separate calls to DrawText. If you drew the whole thing to a bitmap first, then just updated the focus rect on each frame, that would likely significantly improve performance. There’s no reason you shouldn’t be able to do animation on the Roku 1 for that screen.
That worked well! Seems to run much smoother now I’m only drawing the keyboard as a single image. Still not looking quite how I envisioned but it’s getting there!

[upload|DHY4AJ8OftuY2/804xG+ag==]

“TheEndless” wrote:

“JordanT92” wrote:
My next questions is… To speed things up from a data standpoint, I want my app to download a ZIP / JSON file on startup, and use that as the central database for everything, so the only time any network activity would occur is when grabbing images. The only problem is, this file is likely to be around the 20MB mark… Do you think the boxes would be alright with this if I limit playback to 720p? Or would I run out of memory? I can’t seem to find a way of getting my current memory usage…
Yeesh.. I don’t know how that would work out for you. 20MB may be too large for tmp: storage. That should be independent of graphics and video memory, though.

Good point… I didn’t think about TMP storage limits. Does anyone know the limit? I remember reading it somewhere but can’t seem to find it anymore.

“belltown” wrote:

“JordanT92” wrote:
I can’t seem to find a way of getting my current memory usage…

For some reason, Roku doesn’t want you to know anything about memory usage. You can, however, use the r2d2_bitmaps command, issued to port 8080 to get some information about memory usage (at least for your bitmaps).

If you wish to access that information programmatically, it’s possible although rather kludgy, e.g:

truncated...

That’s some useful information right there! I’ll give that a go.

Thanks both.

9

“JordanT92” wrote:

“belltown” wrote:

“JordanT92” wrote:
I can’t seem to find a way of getting my current memory usage…
For some reason, Roku doesn’t want you to know anything about memory usage. You can, however, use the r2d2_bitmaps command, issued to port 8080 to get some information about memory usage (at least for your bitmaps).

If you wish to access that information programmatically, it’s possible although rather kludgy, e.g:

truncated...

That’s some useful information right there! I’ll give that a go.

Thanks both.
Note that port 8080 and the r2d2_bitmaps command are only available if dev mode is enabled on the box, so you can only use this for development purposes. As such, I’m not sure how helpful it would be to code it into the channel itself vs. just opening a telnet session on your dev machine and issuing the command manually.

10

“JordanT92” wrote:
Hello, I’m developing my first app using roScreen the ifDraw2D components, the built-in roku search screen doesn’t quite suit my needs so I’m currently designing the search screen of my app. I want this to be quick and snappy to navigate and search, I’ve designed the keyboard using a basic layout and below it, it will display results grapped asynchronously while you’re inputting. Are there any tips I can use to increase performance as right now it seems the navigation is a tad behind and I haven’t added the asynchronous search features yet. Does getting the date and time every time I draw a frame have any noticeable effect on performance?

[upload|hR4wuwjJoOjAmWsnkOPWBw==]

Strangely the episode page runs faster, I guess not having to draw the alphabet of squares improves performance..?

[upload|ZKgV7UxdmWUToHB8VprGzQ==]

Any tips or hints would be great!

Many thanks, Jordan.

Hi Jordan,
Hi its kind of off topic. I really like the layout of your keyboard. I am creating a custom keyboard screen which is similar to the one your created for search screen. Can you please tell me how would I create it.

Do I use roScreen, roBitmaps, roRegion? And which method did you use to draw the alphabet in the keyboard.

Thanks in advance.

11

For one thing, make sure you create your fonts only once. Do not create them each time you draw a frame, which by the way I’m unclear about. A frame could mean several things. Be a little specific, show some code and it will help to determine where your problem is. Creating a font each time you draw something is the biggest performance hit. Using GetOneLineWidth can also be a performance hit on the low-end devices. If done properly, a keyboard is a simple structure that should have no performance problems on any device. Predefine as much of your static data as possible and keep it in an array or AA. X,Y coordinates etc. For example, the letter A will always be at a static x, y coordinate offset from the cell that it occupies since you probably will be centering it. You should not have to l_x = int( cellWidth/2 - font.GetOneLineWidth( “A”, cellWidth ) / 2 ), l_y = int( cellHeight/2 - font.GetOneLineHeight() / 2 ) each time you draw A into the cell. Iterate your letters and numbers in a loop and pre-calculate and store their offsets. When your selector comes to that cell then you just have to pull the predefined offsets out of the array.
Certainly putting any number of things in what you call a frame can slow it down.

12

“belltown” wrote:

For some reason, Roku doesn’t want you to know anything about memory usage

The architecture of the Brightscript VM doesn’t lend itself to getting this information except by rather hackish methods that might cause the VM to crash and reboot the device. We would love you to have that information.

  • Joel