Roku Developer Program

[oomzay]

Background: At 60 FPS the "screen.SwapBuffers()" call has to block for VSYNC. The return from SwapBuffers() therefore provides a robust sync point for field-rate animation. At a nominal 30 FPS the SwapBuffers() call does not block (*) so it provides no synchronisation with VSYNC at all. Time-based animation can ameliorate this lack of sync to some extent but it would be much better to hit every second field reliably. So...

Is there any way to lock a nominal 30 FPS animation to VSYNC?

One option has occured to me: I could render each frame to a bitmap and then copy the bitmap to the screen twice at two consecutive VSYNCs +15mS, just as if it was a 60 FPS animation. This would maintain the sync but waste at least 1ms of precious cpu time in the middle of each 30 FPS frame - I might try this if there's no other option.

(* This behaviour may be platform dependent? Tested platform: Model: 2400SK, Firmware: 075.05E00430A)

[oomzay]

One option has occured to me: I could render each frame to a bitmap and then copy the bitmap to the screen twice at two consecutive VSYNCs +15mS, just as if it was a 60 FPS animation.

...well I tried this out and it looks significantly better to me than time-based animation alone ...especially with sharp edged, fast moving objects. Of course better to keep within 60FPS if possible - but this technique allows me to trade off FPS against a richer animation without getting any judders - and will almost certainly be needed on slower platforms.

If there is a more efficient way to acheive this I'd still like to hear. This technique wastes a 1mS or so in the middle of each 30FPS frame - not to mention the 2 full screen bitmaps I would not normally use.

[oomzay]

Just to wrap this up, over in a related thread RokuJoel has explained that this problem is specific to "Giga" platforms:

"RokuJoel" wrote:
The issue you are seeing is as I understand it a platform dependent issue (affecting our "Giga" series of hardware, the Roku 2 XS/XD, LT2400, 2400SK, MHL Streaming Stick and possibly the USB stick). Essentially SwapBuffers will de-sync from the vertical blanking interval if you take more than 16 ms before calling it. This was a hack to improve performance of our home screen on these hardware platforms.

So the workaround is indeed to contrive to call SwapBuffers every 16mS or less.