Roku Developer Program

[NewManLiving]

Well I can tell you one thing. When I tried removing finish from my scrolling lists using the streaming stick the old row is cleared with the background color and the new row is drawtexted in, both done by the bitmap and not the region. Then the region is offset to expose the new row. Removing region.finish in the easing loop after each offset caused the drawrect used to clear the line not to be executed thus causing the new text to appear over the old. So I went back and used bitmap.finish after the drawrect and drawtext since I use the bitmap to draw and not the region. This did nothing. So I replaced bitmap.finish with region.finish instead and the problem was solved. So I was able to remove the region.finishes out of the easing loop but I had to use it to commit the bitmap queue even though I used the bitmap to write and bitmap.finish should have done the job. But I ended up optimizing my easing loop. Go figure. Maybe Joel has an answer to this one

[TheEndless]

"NewManLiving" wrote:
Using the compositor I do not initiate any drawing to the screen that I am aware of. Generally I create, write/modify, destroy and then when all is done I call compositor.drawall and swapbuffers. So it would be the compositor that initiates drawing to the screen. so I am trying to figure out how your solution would apply or perhaps I'm misunderstanding you.

Using the compositor, you'd do the same thing. Make all of your compositor/sprite updates before initiating your draw to the screen.

' Update all of your sprites
....
' Now do the screen draw
screen.clear(backgroundColor)
compositor.DrawAll()
screen.SwapBuffers()

' Now do any clean up
...

Again, the key is to not clear the screen until after you've completed all updates to the bitmaps you're about to draw to it. It's that screen.clear() that seems to trigger the flaky timing, as that initiates drawing to the screen. Generally speaking, the only change you should need in your code is to move the screen.Clear() to just before the compositor.DrawAll() call.

[TheEndless]

"RokuMarkn" wrote:
In OpenGL implementations, Finish() calls glFinish(). In DirectFB implementations, it calls WaitIdle(). You can read the documentation for those calls for more detail, but if you don't call Finish, you're relying on timing to ensure that all drawing operations to a bitmap are complete before you use the contents. Depending on the timing of your app, this may well work, but it's risky and if some later change causes timing to change, your code might start failing unexpectedly.

--Mark

While I appreciate that explanation, this was never an issue until the new home screen UI was released, and it doesn't happen on the Roku 3, ever, which I believe is also OpenGL. It also doesn't explain why it happens even if you're not drawing the particular item to the screen. How could an un-Finished() bitmap that's not even being drawn to the screen cause a tear? See the example that EnTerr posted earlier in this thread, as it demonstrates the issue perfectly without any actual draws to the screen: viewtopic.php?f=34&t=54513&p=438746#p438741 (It also, incidentally, draws faster than the 17ms threshold that Joel suggested was the cause earlier, yet still tears).

To me, this clearly looks like a bug that was inadvertently introduced when the optimizations were made to support the new home screen, and was incorrectly attributed to the 17ms threshold for v-sync change.

[NewManLiving]

"TheEndless" wrote:

"NewManLiving" wrote:
Using the compositor I do not initiate any drawing to the screen that I am aware of. Generally I create, write/modify, destroy and then when all is done I call compositor.drawall and swapbuffers. So it would be the compositor that initiates drawing to the screen. so I am trying to figure out how your solution would apply or perhaps I'm misunderstanding you.

Using the compositor, you'd do the same thing. Make all of your compositor/sprite updates before initiating your draw to the screen.

' Update all of your sprites
....
' Now do the screen draw
screen.clear(backgroundColor)
compositor.DrawAll()
screen.SwapBuffers()

' Now do any clean up
...

Again, the key is to not clear the screen until after you've completed all updates to the bitmaps you're about to draw to it. It's that screen.clear() that seems to trigger the flaky timing, as that initiates drawing to the screen. Generally speaking, the only change you should need in your code is to move the screen.Clear() to just before the compositor.DrawAll() call.

Thank you. It seems though, that is what I have been doing except I do not clear the screen as Compositor.SetDrawTo takes an rgbaBackground as an argument. I would guess that it has been clearing the screen as there was never a problem with rendering anything. Some people including myself have used the screen.clear or screen.finish prior to Compositor.DrawAll to get rid of the flickering. This worked for me most of the times but I still had problems. Not until I started getting aggressive with the finish methods did I see a total eradication of the occasional flashing. Now I'm trying to see what relationship roRegion.Finish has to roBitmap.Finish and do I need to use both or does either one take care of whats been queued ( do they both have separate queues ???). It would seem that if you use the bitmap you call bitmap.finish and if you use the region you call region.finish. From my above post the only one that worked was roRegion.Finish , even though the bitmap methods were used for drawing and not the regions. The region was not yet even offset into that area of the bitmap. It gets offset in the easing function to give the scrolling effect. So I don't understand why bitmap.finish did not work but region.finish did. so far I have been able to remove all the finishes from the easing loop which take up 80 % of processing in my grids and lists and place one outside the loop and then just offset * percent of framerate, without region.finish after each offset. This produced a further improvement on the roku 1 box. But I'm puzzled as to why I could not get the bitmaps drawrect to commit unless I used region.finish, like I said I should have been able to use bitmap.finish. I think I could modify the scrolling list example I submitted earlier and try to reproduce it

[TheEndless]

"NewManLiving" wrote:
Thank you. It seems though, that is what I have been doing except I do not clear the screen as Compositor.SetDrawTo takes an rgbaBackground as an argument. I would guess that it has been clearing the screen as there was never a problem with rendering anything.

I always assumed that background color was just what was used to clear the relevant portions of the screen when calling compositor.Draw(). I suppose calling .DrawAll() would cause it to clear the whole screen, but I've always initiated screen draws, compositor or no with a screen.Clear() first. As this fixes the issue 100% of the time (in every case I've tested), it seems like a much easier and more appropriate fix than adding .Finish() calls throughout your code, but I don't know what all you're doing in your code, so I can't state that definitively.

With that said, as I recommended to RokuMarkn in my last post, please test out the example EnTerr posted earlier, as that clearly demonstrates that it has nothing to do with .Finish(). I suspect the delay that .Finish() is introducing is more likely the reason it's working rather than the call to .Finish() itself.

And for what it's worth, I've actually found on a few occasions that calling screen.Clear() first actually improves the framerate in certain scenarios. I haven't taken the time to narrow down why (since I always do it now), but a guess would be that it's related to whether alpha blending is enabled or not.

[NewManLiving]

Thank You. I will give Clear another try. But I'm a little concerned about what Mark had to say since removing some of the finishes I did experience partial commits which never happened before.

[EnTerr]

"squirreltown" wrote:
… if my timing is based on swapbuffers() which is a minimum of 16 ms then the scary timing …

Let me make a side point, since this is flat out wrong and I have seen it stated before. swapBuffers() has no minimum, it can be as low as 1 or "0" ms. It can take anywhere between 0 and 17ms for it to get in sync with the video signal, so one can loosely say its MAXIMUM is 17ms.

Ps. Typing on a phone sucks boba pearls

[squirreltown]

"EnTerr" wrote:

"squirreltown" wrote:
… if my timing is based on swapbuffers() which is a minimum of 16 ms then the scary timing …

Let me make a side point, since this is flat out wrong and I have seen it stated before. swapBuffers() has no minimum, it can be as low as 1 or "0" ms. It can take anywhere between 0 and 17ms for it to get in sync with the video signal, so one can loosely say its MAXIMUM is 17ms.

Ps. Typing on a phone sucks boba pearls

Thanks for the correction. Typing on the phone is eh..ok, but trying to remove the non-relevant part of the quotes is what gets me.

[EnTerr]

"TheEndless" wrote:
While I appreciate that explanation, this was never an issue until the new home screen UI was released, and it doesn't happen on the Roku 3, ever, which I believe is also OpenGL. It also doesn't explain why it happens even if you're not drawing the particular item to the screen. How could an un-Finished() bitmap that's not even being drawn to the screen cause a tear?

I think @RokuMarkn was answering narrowly a side question asked by @Squirreltown (re roBitmap.finish()) and not opining on the issue at large.

Check out what i found out today

"OpenGL.org wiki" wrote:
Adaptive Vsync
Recent GL drivers implement a new WGL/GLX extension called EXT_swap_control_tear. This extension brings "adaptive vsync" as featured in modern gaming consoles to the PC. Adaptive vsync enables v-blank synchronisation when the frame rate is higher than the sync rate, but disables synchronisation when the frame rate drops below the sync rate. Disabling the synchronisation on low frame rates prevents the common problem where the frame rate syncs to a integer fraction of the screen's refresh rate in a complex scene.

I have realized before on my own (and talked about) the property of "hard vsync-ing" leading to only a few, fixed effective FPS (divisors of 60: 60, 30, 20, 15, 12, 10...). With "adaptive vsync" however, things become more interesting - not necessarily in a bad way. I don't have good grasp of it yet but intuitively it will keep the synchronizing effect if we take under 17ms on most frames, while not causing obvious "jank" (skipping frames) on occasional >17ms. However, if we take >17ms on (most) all frames, that'd guarantee a persistent tearing.

Read the rest of that page as well as http://stackoverflow.com/a/24136893/226086 for some mind-blowing revelation. I think i'll leave my head exploding for a while and only try to -re-assemble after the fallout.

[TheEndless]

"EnTerr" wrote:
[Adaptive Vsync Info]

That would be in line with RokuJoel's assertion above, but it doesn't explain why your example causes the tearing. None of those initial frames take anywhere near 17ms. Maybe there are two issues at play here, but I think your example demonstrates the more likely common cause.