can the background be drawn?

[Cliff3D]

So, reading and re-reading the help file to try and deduce what's happening brings me down to a third iteration of my interpretation of the SHOWSCREEN command, as attached. This leads to three basic questions which I think fundamentally affect whether Gernot can significantly improve speed of screen updates for us across all platforms:

1) What does the "Swap BackBuffer and FrontBuffer" process/stage actually DO? Does it copy the BackBuffer to the FrontBuffer, or something else?

2) Can the "Copy BackImage over BackBuffer" process be optimised so that it does this in the FASTEST possible way, matching or beating similar processes that currently outpace using the BackImage?

3) If the current "Swap BackBuffer and FrontBuffer" process copies screen data in the same kind of way that the current "Copy BackImage over BackBuffer" process does, can it likewise benefit from some optimisation to improve the speed of every single SHOWSCREEN command?

[attachment deleted by admin]

[ampos]

As on old Amiga double buffer works, was that way: you have 2 memory zones or screens. The displayed one was a pointer. Then you were writing in the other memory/zone. When you finished painting just told the system to change the pointervto the other screen and the new gfx operations were performed on the new hidden one.

Think like having two pieces of paper, one in each hand. You show one and paint on the other. On showscreen just change your hands. So no copy was made from one buffer to the other. Jus the front becomes the back and the back the front.

[Cliff3D]

As on old Amiga double buffer works, was that way: you have 2 memory zones or screens. The displayed one was a pointer. Then you were writing in the other memory/zone. When you finished painting just told the system to change the pointervto the other screen and the new gfx operations were performed on the new hidden one.

Yup-and other old computers that predate the Amiga, too. The thing is, if it's pointers that are changed and not memory contents that are copied, then Clearscreen -1 might not save as much time as you may be hoping for - because there is no "old copy" of the screen to leave in place. Optimising "ClearScreen" and "UseAsBMP" to be faster might be a better option, if possible. Although ClearScreen -1 should always save SOME time if one is going to redraw the entire screen each frame (as in from a sprite or "Usescreen", for example).

[Kitty Hello]

And here is the "undefined" parameter.
On OpenGL (Win32, Linux, Mac, iPhone) I actually swap as you did on the Amiga.
Same for GP2X.
On the Wiz I have to "copy" to the framebuffer (could not get the swap registers working).
On WindowsCE it totally depends on the device drivers if I swap or copy.

[ampos]

But the question is why is slower the things that should be faster... 

[Kitty Hello]

But when you swap the buffers, the new "back" has the contents of the old frame drawn. Thus, I had to glClear(GL_COLOR_BUFFER) it.

[Cliff3D]

And here is the "undefined" parameter.
Paraphrased: Sometimes it's a pointer swap, sometimes it's the whole screen copied, depending on the platform.

I had a horrible feeling you were going to say that. So on some devices we could be looking at a modest speed improvement (though many a mickle makes a muckle/every little bit helps).

Could I ask which technique is used on the various iDevices, especially the older ones?

But the question is why is slower the things that should be faster... 

Indeed - or to rephrase "can GLBasic use the best speed techniquesfor the commonest functions please".

But when you swap the buffers, the new "back" has the contents of the old frame drawn. Thus, I had to glClear(GL_COLOR_BUFFER) it.

So the BackBuffer would not contain the most recent screen image, but the frame before it? If this is consistent, and you can find a way to document it such that App authors can grok it easily enough, this still could be more useful left intact - saving some overhead in reproducing the screen contents to that point - in some cases, rather than always wiping it. A ClearScreen -1 would leave us with two new choices:

1. Paint the whole screen from scratch -as we might need to do even with the screen being cleared.
2. Rebuild the screen changes for the last frame then add the next frame's changes.

For certain types of App either of these MIGHT be a benefit over the current scenario - though I am a little concerned that in some situations glClear(GL_COLOR_BUFFER) might be so efficiently performed by a seperate GPU that it will be hard to see any improvement in speed for many apps

It would still be "nice" if the Backimage copy were at least as fast as using a Sprite to achieve the same ends, unless there's a specific reason that it is slower?

[Kitty Hello]

many games overdraw the whole background with animated stuff. Here, a glClear is not needed. I use the flip on iDevices, and try the fastest output possible on all devices. Test it, GLBasic really is fast. Often faster than SDL. Especially blitting.
Do not rely on what's on the back buffer after a flip. It also depends on what the driver does. There's no definite way of telling.

[ampos]

But way is faster to draw a full screen sprite than loadbmp?

[Kitty Hello]

no. Loadbmp does exaclty that. But! When you draw an animated background, you don't want the clear.

[ketil]

Well ... why not start with an implementation of CLEARSCREEN -1 ?

[Cliff3D]

many games overdraw the whole background with animated stuff. Here, a glClear is not needed.

Agreed. A CLEARSCREEN -1 capability would be nice for these situations

I use the flip on iDevices

A shame. While it seems unlikely, it would always be nice to discover that a small change might result in a large speed improvement ;(

and try the fastest output possible on all devices. Test it, GLBasic really is fast. Often faster than SDL. Especially blitting.

No doubt - indeed, many of my posts in this vein have been warnings that due to this or that, we might not get the speed improvements that SEEM "obvious", because it seemed likely to me that you would have fairly optimised code, and that "obvious" solutions might not, in the end, provide such improvements

Do not rely on what's on the back buffer after a flip. It also depends on what the driver does. There's no definite way of telling.

This is the saddest thing

But way is faster to draw a full screen sprite than loadbmp?

no. Loadbmp does exaclty that. But! When you draw an animated background, you don't want the clear.

Ian has done tests  which suggest otherwise:

loadbpm "my static background.png"

Actually, a simple test appeared to show that this is  actually the least efficient way to display a background on my laptop. Using a standard sprite proved best for me.

I've included my test (.EXE and code). Maybe the test is flawed, but there's a significant difference between the four tests.

Perhaps there is some flaw in Ian's testing (perhaps you could check his tests):

http://www.glbasic.com/forum/index.php?action=dlattach;topic=5258.0;attach=2496

but otherwise there seem to be some odd differences in speed between certain methods, and a sprite appears to be faster than using a background image We'd love to know why/have background images sped up

[ampos]

TEST @ iPhone 3G

A.- without "clearscreen -1"

1: 60 no background
2: 43 drawsprite
3: 43 polyvector
4: 60 loadbmp

B.- with "clearscreen -1"

1: 60 no background
2: 38 drawsprite
3: 38 polyvector
4: 60 loadbmp

Very strange results... will change my program "sandscape" to clearscreen -1 and/or drawsprite to check fps...

Upd:

1.- my program loses 1-3 fps if using drawsprite instead of loadbmp.
2.- clearscreen -1 wins 1-2 fps on loadbmp and lose 4-5 in drawsprite vs loadbmp.

Very strange, again.