Roku Developer Program

[jbrave]

1. If a channel has a screensaver associated with it and you call RunScreensaver from within the channel, what happens when 5 minutes has passed and the system goes automatically to screensaver. Are they both running at the same time or does RunScreensaver override the system call to RunScreensaver?

2. If a channel that does roimagecanvas displays is running and its own screensaver comes on, is cpu still being used up in doing the channel graphics while the screensaver is running?

3. If I'm playing audio and my channel screensaver comes on automatically when there is no user activity, the screen goes dark for 5 minutes or more before the screensaver starts drawing to the screen. However, If I call RunScreensaver() it starts immediately. Is there anything I can do to speed this up? I'm guessing this has to do with cpu usage?

- Joel

[TheEndless]

"jbrave" wrote:
1. If a channel has a screensaver associated with it and you call RunScreensaver from within the channel, what happens when 5 minutes has passed and the system goes automatically to screensaver. Are they both running at the same time or does RunScreensaver override the system call to RunScreensaver?

You'll have two screensavers running. Calling RunScreensaver internally does not override the system screensaver timeout.

"jbrave" wrote:
2. If a channel that does roimagecanvas displays is running and its own screensaver comes on, is cpu still being used up in doing the channel graphics while the screensaver is running?

Yes. The screensaver runs in a separate thread on top of whatever is currently running, so your channel processing will continue while the screensaver is displayed.

"jbrave" wrote:
3. If I'm playing audio and my channel screensaver comes on automatically when there is no user activity, the screen goes dark for 5 minutes or more before the screensaver starts drawing to the screen. However, If I call RunScreensaver() it starts immediately. Is there anything I can do to speed this up? I'm guessing this has to do with cpu usage?

Playing audio definitely slows things down, but it certainly shouldn't slow it down by 5 minutes. All three of my audio apps (SiriusXM, MainSqueeze, and Shoutcast) have screensavers that display the now playing information, and they come up pretty much immediately, so it sounds like you might have something else going on that's slowing yours down... I'd be willing to bet it's the roOneLineMessageDialog that you're regularly popping up. I discussed its performance penalties in another thread a couple months ago.

[jbrave]

Thanks for getting back to me.

I guess that means we need a way to check if the screensaver is running. That is pretty easy to do by passing files via tmp:/ except in the condition where someone hits the home button, which appears to kills the screensaver without allowing it to clear out any files that it uses to pass signals to the running app, and drops you back into the running main app. ( I'm testing this right now - exit with

Any ideas for a mechanism that might resume activity in the main app if someone terminates the screensaver with the home button? I have an idea but it would result in a good amount of file system writes from the screensaver - every 10 seconds have the screensaver write a new "i'm running" message, which the main app looks for every so often. If it is there, shut down all screen output, clear the signal, wait, say 20 seconds and check again, if the signal file is not there, start screen output again.

Do you know if the tmp: filesystem is flash or RAM? Not sure if doing heavy writes to flash is a good thing.

- Joel

[TheEndless]

"jbrave" wrote:
I have an idea but it would result in a good amount of file system writes from the screensaver - every 10 seconds have the screensaver write a new "i'm running" message, which the main app looks for every so often. If it is there, shut down all screen output, clear the signal, wait, say 20 seconds and check again, if the signal file is not there, start screen output again.

That's the route I took originally, before I just decided I didn't need to know when the screensaver was running, due to similar reservations. I also didn't like the hackiness of it.

"jbrave" wrote:
Do you know if the tmp: filesystem is flash or RAM? Not sure if doing heavy writes to flash is a good thing.

I'm not sure, but since the audioplayer example in the SDK takes a similar approach (see the IsMainAppRunning() function in screensaver.brs), I'd assume it's ok, and blame Roku if it turns out not to be... 😛

[RokuKevin]

/tmp may write to flash, so I wouldn't recommend a tight loop writing to the file system.... However, you are encouraged to use patterns you see in the SDK in your own channels. We do recommend this as a way to communicate between your main app and screensaver thread.

--Kevin

[kbenson]

"RokuKevin" wrote:
/tmp may write to flash, so I wouldn't recommend a tight loop writing to the file system.... However, you are encouraged to use patterns you see in the SDK in your own channels. We do recommend this as a way to communicate between your main app and screensaver thread.

May write? Is there any chance we can get some info on when that's likely to happen? KidPaint writes to /tmp quite a bit, it would be nice to know if there's ways we can minimize writing to flash.

[jbrave]

I would like to ask for some serious feature requests here:

1. a global screensaver property and global main app property as part of roDevice Info: IsScreenSaverRunning() and IsMainAppRunning() that does not write to the flash memory.

2. a messageport: screensaver.SetMessagePort(port) and App.SetMessagePort(port) where the two can exchange messages of type "RoScreenSaver" and "RoApplication"

Think that might be possible in 2.9?

[RokuKevin]

I say may write because it's an implementation detail that we are likely to optimize in the future. To be safe, you should code as if it would be writing to the flash. Our sample app writes to the tmp file system only when the cover art changes (every couple minutes).

--Kevin

[kbenson]

"RokuKevin" wrote:
I say may write because it's an implementation detail that we are likely to optimize in the future. To be safe, you should code as if it would be writing to the flash. Our sample app writes to the tmp file system only when the cover art changes (every couple minutes).

KidPaint writes to /tmp on every image placement. The reason for this is twofold; We need to rewrite the PNG header info for the simple shapes to set the correct color, so we copy the base image and rewrite the header. The second reason (and why we do this for ALL images, not just ones we change the color for) is that there is (was?) a bug when placing an image in an roImageCanvas where if it was scaled at all, the next placement is pre-scaled. Thus, if we placed an image that was doubled in size, the default size for the next placement of the same file is doubled in size. This bug may not be present in newer versions, we haven't tested that recently.

If the bug mentioned above is already fixed (or can be soon), we can change the way we place images to use the ones shipped in the package, and only create a single shape/color combination as required and use that as the base. We sure don't want to be responsible for wearing out the flash, and we can write a lot of files to /tmp in a run, 40+ isn't out of the question for normal use.

[jbrave]

Can I get a definitive answer from Roku on what is a safe write cycle? In order to create a reasonably performing screensaver that shuts down the main app when it is running and resumes the app when it finishes, I will be writing to temp every 25 seconds. Is there any reasonable concern that this might reduce the life of a roku device? It's a choice between that and using double the bandwidth since the screensaver I'm working on will be doing exactly what the main app does.

-Joel