The screenshot utility on the roku web page seems to take the jpeg from the roScreen back buffer, not the onscreen buffer. Just wanted to report that it makes it more difficult to get a screenshot when you use an roScreen. The workaround is to force your channel to update i.e. SwapBuffers(), just before taking your screenshot.
Thank you for this report. Did you notice this behavior change in firmware 4.8 or has this always been the behavior you have seen?
I didn’t get a chance to test this in 4.7. Only tested in 4.8 build 1178, US Model Roku 2 XS.
I’ve seen this behavior with 4.7 as well as 4.8 - usually waiting a bit after it draws the screen fixes it for me - this is with using goto loops in the script where the screenshot will display half or a third of the drawn screen sometimes. Clicking screenshot a few times will eventually display the whole image.
I tested (again, 4.
pressing the screenshot (html submit) button in firefox at one minute intervals for five minutes and it still is taking from the previous back buffer (the one that is supposedly “in a garbage state”). For good measure right before I posted this message, after 10 minutes since the SwapBuffers() call and still the same. Then for good measure, I pulled it up in IE (to avoid potential browser cache issues) and get the same result 15 minutes after the last SwapBuffers() call.
From ifScreen:
“The back buffer should be assumed to be in a garbage state after this call [to SwapBuffers()] is complete.”
I know in my code that I don’t call SwapBuffers() unless there is user input (or async input, which in this case there is none). Perhaps I see this because it is different than uses of roScreen that use animation.
Hopefully this sufficiently brackets the problem for you…
Also note an unrelated documentation error:
http://sdkdocs.roku.com/display/RokuSDKv48/roScreen
If three parameters are passed, the second two specify the screen’s resolution. The dimensions must be one of the screen sizes specified above.
CreateObject(“roScreen”, true, 720, 480) ’ db & SD res
I think should read “If four parameters are passed, the last two specify…”
Perhaps that issue is happening when you are creating a double buffer roscreen and have never called swapbuffers before, at least in that case it is showing the previous screen here (an roimagecanvas) rather than a backbuffer that doesn’t have anything on it.
“destruk” wrote:
Perhaps that issue is happening when you are creating a double buffer roscreen and have never called swapbuffers before, at least in that case it is showing the previous screen here (an roimagecanvas) rather than a backbuffer that doesn’t have anything on it.
I do think that can happen. Though it’s not happening in my particular case, as by the time I take the screenshot, I have called SwapBuffers() many times.
There definitely is (unsupported) interaction between roScreen components and the roScreen component. See here for more background. Based on my observation, the interaction specifically involves the back buffer on the roScreen. Since that linked post, I have reworked all my code to make sure that when roScreen is created/shown, it is the only expected interactive component. And before I use another roScreen component, I Close() the roScreen.
The component stack seems to be operating as expected with this usage.
