"RokuMarkn" wrote:
Also note that SwapBuffers waits for the next vertical sync, so it's expected that it could take up to 16 ms. That's not a performance problem, it's the way SwapBuffers has to work.
"EnTerr" wrote:
This is a profound note worth highlighting, so i'll paint it red:"RokuMarkn" wrote:
Also note that SwapBuffers waits for the next vertical sync, so it's expected that it could take up to 16 ms. That's not a performance problem, it's the way SwapBuffers has to work.
What it means is that when using double-buffered roScreen, you cannot get frame rate higher than 60fps. And I mean never. Ever. Because that is how it works, vsync happening 60 times per second (silence procedure[/url:37xh8484]), no more that 60 SwapBuffers() can pass per second.
I ran into this...
"TheEndless" wrote:This operation can be extremely fast (that is, it never copies a bitmap from one location to another) but in double-buffered mode it is guaranteed not to "tear" the visible image, so it waits for the next vertical sync and can take up to 17ms.
It's also no longer guaranteed not to "tear" the visible image on the previous gen hardware (including the new stick). I believe this is a bug, and I've just about got the example worked out that I can pass along to Roku, so they can hopefully address it. In short, if you create an in-memory bitmap (i.e., not from a path) after you've initiated drawing to the back buffer, but before you call SwapBuffers(), you're more or less guaranteed a tear/flicker.
"EnTerr" wrote:"TheEndless" wrote:This operation can be extremely fast (that is, it never copies a bitmap from one location to another) but in double-buffered mode it is guaranteed not to "tear" the visible image, so it waits for the next vertical sync and can take up to 17ms.
It's also no longer guaranteed not to "tear" the visible image on the previous gen hardware (including the new stick). I believe this is a bug, and I've just about got the example worked out that I can pass along to Roku, so they can hopefully address it. In short, if you create an in-memory bitmap (i.e., not from a path) after you've initiated drawing to the back buffer, but before you call SwapBuffers(), you're more or less guaranteed a tear/flicker.
That is odd.
Do i understand right, if you call createObject("roBitmap") while in midst of painting to back buffer, it will prematurely show the back buffer, before SwapBuffers being called? Also if you keep painting after that createObject but before swapBuffers, where does that go?
screen = CreateObject("roScreen", True, 1280, 720)
While True
' Initiate drawing the the back buffer by clearing it.
screen.Clear(0)
' Create a bitmap in memory. We're not going to use it for anything.
' I believe the allocation of memory is what causes the flicker/tear.
' Comment this line out, replace it with a roBitmap created from a local path, or just move it above the Clear() and the flicker goes away.
bitmap = CreateObject("roBitmap", { Width: 100, Height: 100, AlphaEnable: False }) 'Height and Width don't matter here
' Draw a red rect over the screen to make the issue more apparent
screen.DrawRect(0, 0, 1280, 720, &HFF0000FF)
screen.SwapBuffers()
End While
"TheEndless" wrote:
it just causes a flicker/tear in the screen during the SwapBuffers(), like the draw never completes. Here's a quick sample that causes the issue.
arr = [] 'prep me 100 bitmaps to dropRun this and watch the console - screen "tears" only until the initial ammo of 100 bitmaps is exhausted and after that is all-red.
for i = 0 to 100:
arr.push( createObject("roBitmap", { Width: 10, Height: 10, AlphaEnable: False }) )
end for
screen = CreateObject("roScreen", True)
While True
screen.Clear(0)
? arr.pop()
screen.Clear(&hFF0000FF)
screen.SwapBuffers()
End While
"EnTerr" wrote:
But the fun part is, bug does not happen when roBitmap is created but when it is disposed!
"EnTerr" wrote:
Run this and watch the console - screen "tears" only until the initial ammo of 100 bitmaps is exhausted and after that is all-red.
"EnTerr" wrote:
Have you flagged someone @Roku on this or should we start jumping up and down waving till someone notices?
"TheEndless" wrote:"EnTerr" wrote:To test that properly, you probably need to create the bitmaps inside the loop as well. The way you've done it in this example excludes that variable by creating them in advance, so it could possibly be an "as well".
Run this and watch the console - screen "tears" only until the initial ammo of 100 bitmaps is exhausted and after that is all-red.