Roku Developer Program

[MazeWizzard]

Check me on this gang. The following

msg = wait(1, msgport)

is coming in at around 15 milliseconds. Now, for a 30 fps render loop I only have a 33.33 millisecond window to operate in. The render loop requires getting user input. Now, on a Roku 1 this comes in at 1 ms (still too long in my opinion, but I can probably live with it). On the roku 2 boxes they have "hooked" the wait/sleep routines for other purposes, or they otherwise take longer, such that it is using almost 50% of my available time... not to render but to check for remote input. I still have to render when done waiting for input.

Maybe it's me. Can someone check on this and confirm? It makes a Roku 2 render loop almost impossible in BrightScript if I'm correct.

Maybe they could check if they are "in game mode" and not take so long with whatever it is doing on a Roku 2 vs a Roku 1????

Pardon my post if this is already a known issue...

Thanks in advance for the feedback.

MW

EDIT: I should note that the wait is on a ro UniversalControlEvent for an roScreen.

[TheEndless]

I can confirm that I'm getting ~15ms on the first wait, then 10ms consistently after that. The same if I use a Sleep(1) instead. On the Roku 1, I'm getting 1 ms as expected.

"MazeWizzard" wrote:
Now, on a Roku 1 this comes in at 1 ms (still too long in my opinion, but I can probably live with it)

I don't understand this comment. You're telling it to wait 1 ms... why would you think it actually taking 1 ms would be too long?

[MazeWizzard]

It only means that if there is no pending input, why wait a whole millisecond (we've been down that road before with the wait thing in several other posts.... but 0 means wait forever, and there is no -1 or other way to return immediately). Its not that I didn't expect 1 ms, just annoyed that I have to wait 1 ms rather than having an option of returning immediately if no input is available.

Anyway.. that's a distraction... an offhand side-comment that I should have omitted. The point is "what is it showing for others on a roku 2... 15 ms ish?"

However...Thank you for the confirmation. 15 then 10 ms. OK. Confirmed.

[RokuJoel]

you could perhaps optimize a bit by only checking for input every x milliseconds or so:

if timer.totalmilliseconds() > 100 then
    msg=wait(1,port)
    timer.mark()
end if

Meanwhile, I've verified the issue and filed a bug report.

- Joel

[MazeWizzard]

Thanks RokuJoel. IDK what it is... hope there's a "smoother" solution to whatever it is doing.

I had considered checking for input every other loop, or every 3rd, or whatever. That would average the negative impact out a bit. I still need to check the R2's timing on the AnimationTick() and Draw()/DrawAll() routines... maybe they are faster on an R2 and it will all work out. I still have options for dropping fps target down a bit too I guess.

I agree that its either a "bug" or an "undocumented feature difference" (?lol?) between the two boxes.

Anyway.. thanks for taking the time and for the support.

[RokuKevinG]

Assuming I am understanding your use case correctly, you don't need to call wait() at all. Just do this:

msg = port.GetMessage()
if type(msg) = "roUniversalControlEvent" then
<act on message>
end if

No waiting required, and you're not subject to the bug.

- kevin

[MazeWizzard]

You guys rock. It worked.

I thought you had to bind it to the roScreen (via SetPort() ) and go through that via a wait. Obviously not. Good to know. Missed the GetMessage() part of the port object. Many of the examples have Wait() in them, so that's what I thought you did! :? :oops: Guess I should check out roMessagePort more closely....

I can always create my own self-timed sleep() if needed at all.

Thanks!

[RokuJoel]

Rather than using sleep to control event timing, as sleep() and wait() suffer from the same issue, consider using several roTimeSpan objects to trigger events at a specific duration:

timer=createobject("rotimespan")
timer.mark()

then:

if timer.totalmilliseconds() > 25 then
timer.mark()
executemytimedfunction()
end if

or, reset the timer after executing your event:

if timer.totalmilliseconds() > 25 then
executemytimedfunction()
timer.mark()
end if

Depending on if you want, for example 25 ms between events, or 25ms inclusive of event execution time.

Very useful for updating multiple objects on the screen at different intervals.

- Joel

[TheEndless]

"RokuJoel" wrote:
Rather than using sleep to control event timing, as sleep() and wait() suffer from the same issue, consider using several roTimeSpan objects to trigger events at a specific duration

Assuming you mean inside a while loop (can't think of any other way to track it), without a sleep in there, that sounds like a really good way to lock up the box, particularly if you're not listening for any events. But, if you add wait in there to catch any events (and to give the processor some breathing room), you're right back to square one.

[destruk]

Would using a goto work?
ie from the deviantart sample - minorly modified

collectinput:
msg = port.GetMessage()
If Type(msg)="roPosterScreenEvent"
If msg.isListSelected()
<pass item data to video player>
end if
end if
goto collectinput


To basically remove any reliance on sleep or wait specific commands. Since it's a poster screen, the up and home and back buttons are hardcoded and handled already so the box shouldn't die. ? Or you could use this for a roImageCanvas handling each specific button within the goto loop - possibly with a timer as suggested to draw the screen at set intervals faster than the enforced 15ms/10ms delay?

Personally though, I would really prefer if it was changed back to closer match the roku1's timing if at all possible.