can the background be drawn?

[matchy]

I'm terribly confused about this thread. Could someone post some example code to display (and keep) a static background image, sprite or bmp file the most efficient way plzzzz!!!1!!11 .

[ampos]

I'm terribly confused about this thread. Could someone post some example code to display (and keep) a static background image, sprite or bmp file the most efficient way plzzzz!!!1!!11 .

loadbpm "my static background.png"

[Cliff3D]

I'm terribly confused about this thread. Could someone post some example code to display (and keep) a static background image, sprite or bmp file the most efficient way plzzzz!!!1!!11 .

ampos's response is quite correct and most helpful, but I'd like to add "you're probably confused in part because this thread is NOT about the most efficient way of having a static background, but about making having a dynamic background more efficient".

For example, if we could time our Apps to the "screen refresh" pass, we could (in theory) time our screen drawing directly to the screen memory with no snow or tearing or anything.

Now, I don't know the exact internals for how screen handling works in GLB for every device, but there are several steps taken (copying from backbuffer to frontbuffer, then clearing the backbuffer, then potentially copying the static background to the backbuffer) which have a number of effects:

1. It keeps the "ACTUAL screen update" as fast as GLB can possibly manage, which should avoid all snow and/or tearing.

2. It adds processing to do all those jobs, which might not be necessary for some Apps*

3. It wipes the drawing "to date", which may actually mean the App coder has to redo masses of work, further slowing the App.

What we're looking for is to increase the performance of Apps which don't need - or want - the background clearing and rebuilding each and every frame. The "ultimate" of this would be to be able to draw on the screen directly, but in some instances this can cause screen tearing. So you can see why Gernot might be qnti this, as it could cause support issues for those who don't understand screen technology very well. A compromise situation is to not clear the backbuffer when it's copied to the frontbuffer. How Gernot achieves this would depend on the actual techniques used to "swap" and clear the buffers on each platform, but the theory is to reduce the CPU/GPU overhead on screen updates.

[matchy]

Oh. I didn't realize that LOADBMP stays in the fore-buffer.   

[Cliff3D]

Oh. I didn't realize that LOADBMP stays in the fore-buffer.   

Well technically it probably replaces the background image buffer, in much the same way that "UseScreen" can redirect drawing to a sprite instead of the usual backbufffer:

LOADBMP bmp$


Loads the file bmp$ and changes the background image buffer to the image. As a result, it will form the background for your program's display from the next call to SHOWSCREEN.

(from http://www.glbasic.com/xmlhelp.php?lang=en&id=50&action=view)

Probably the key word there is "from". Often the implication of commands (in many language) hinge on the tiniest of words in the definition, and I usually miss them completely.

If no-one does so before I get home in a few days time, I might be tempted to draw up a few flowcharts of ways that GLBasic's screen updates might currently be happening - but they would be based heavily in conjecture (for example, when there is a background image, does Gernot bother clearing the backbuffer before copying the background screen over it? If the background image supports alpha/transparency then it probably needs a clear screen beforehand, if it doesn't then that step would seem to be not required). And so on.

[Ian Price]

I'm terribly confused about this thread. Could someone post some example code to display (and keep) a static background image, sprite or bmp file the most efficient way plzzzz!!!1!!11 .

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.



[attachment deleted by admin]

[ampos]

I'm terribly confused about this thread. Could someone post some example code to display (and keep) a static background image, sprite or bmp file the most efficient way plzzzz!!!1!!11 .

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.

Good catch. On my PC, 1 & 2 (no background & drawsprite) are around 1300 and 3 & 4 (polyvector & loadbmp), 800.

I will compile tonite to iPhone to check if this is also true on iDevices.

PS: it seems we have been mislead (!) by Gernot, as the options that "should be faster" are the slower and viceversa.

[EDIT by Ian] Ampos: your reply was embedded in the quote. Sorted.

[Ian Price]

I get the same ampos - no background and sprite image seem to be twice as fast as POLYVECTOR and LOADBMP. This is surprising.

#1 - 3440
#2 - 3391
#3 - 1447
#4 - 1454

[Cliff3D]

This is one reason that i am hesitant to produce any kind of flowchart that is anything but overly generic to show "how screen updates are done" becuase the fine details - which may be platform specific - could disagree in specific situations with a flowchart. Without being privvy to how and why some routines are slower than others it's a tough call on how and why different scenarios are faster or slower.

In theory a sprite SHOULD IMHO be faster than Polyvector, because a sprite that matches the background dimensions pixel-for-pixel should be a very swift, optimised copy that POLYVECTOR can't compete with because POLYVECTOR has to be able to cope with non-exact size and shape matches. BUT - this can be made "untrue" either by harnessing the GPU for POLYVECTOR and not sprites (so memory accesses are almost all on the graphics card, not having to cross busses to the CPU) for example, or by having sprite code simply being older and unoptimised than the POLYVECTOR code. Examples only of how, on some platforms, sprites could be faster or slower than polyvector.

Why or how the existing "background image" code could perform slower than using a sprite is a mystery to me, as one would have thought that the "background image" would have the most efficient code possible because it has the most certain direct 1:1 correlation, in size, between the background and the backbuffer. It FEELS as if, perhaps, sprite handling has been given some optimisation over the years that the background image copier hasn't. I'd have thought it possible for the background image to be AT LEAST as fast as a sprite (by reusing the same technique/code) if not faster (by optimising based on the background being held in memory as the same dimensions as the backbuffer) but that would require more dev time from Gernot (or perhaps an efficient method of cloning Gernot!)

[ampos]

The fact is that it opens a new entry way for my app to be faster on old iDevices 

[Ian Price]

Why or how the existing "background image" code could perform slower than using a sprite is a mystery to me, as one would have thought that the "background image" would have the most efficient code possible because it has the most certain direct 1:1 correlation, in size, between the background and the backbuffer. It FEELS as if, perhaps, sprite handling has been given some optimisation over the years that the background image copier hasn't. I'd have thought it possible for the background image to be AT LEAST as fast as a sprite (by reusing the same technique/code) if not faster (by optimising based on the background being held in memory as the same dimensions as the backbuffer) but that would require more dev time from Gernot (or perhaps an efficient method of cloning Gernot!)

I totally agree. There are some interesting inconsistancies shown here. Whilst the test itself may be flawed, it is consistant.

POLYVECTOR usage will vary depending on number/size of images being shown (and the host machine's 3D graphic handling) and can be more efficient than using DRAWSPRITE.

[Kitty Hello]

No way to access the front buffer on all platforms.

[Cliff3D]

The fact is that it opens a new entry way for my app to be faster on old iDevices 

Possibly - at least it is the hope, but it depends somewhat how SHOWSCREEN actually WORKS as to whether there is significant room for improvement.

At it's simplest, I imagine SHOWSCREEN does something like the first flowchart here, although obviously the second flowchart would be more efficient when there is a static background image being used (even if that "static" background image is changed every frame by the App, as can be done).

HOWEVER, there is much that is left unclear in these flowcharts - each step could do with being better defined. For example, if the step "Swap BackBuffer and ForeBuffer" involves copying the contents of the BackBuffer to the ForeBuffer then the state of the BackBuffer afterwards is well known and potentially useful (and so having a way to NOT clear it would be great). If, however, the process involves assigning a "ForeBuffer" pointer to the BackBuffer and creating a new BackBuffer memory block, and pointing the BackBuffer pointer at this new memory block, then the contents of the Backbuffer is unknown and removing the "Clear BackBuffer" process from the procedure would not be as helpful as might otherwise be imagined.

Additionally it would be interesting to know if the FrontBuffer (oops I named it wrong above) is the actual display, or if it is indeed a buffer that is copied to the ACTUAL screen display at the termination of the SHOWSCREEN command. I get the impression that the FrontBuffer is the ACTUAL display memory, but I am not 100% positive.

[attachment deleted by admin]

[Cliff3D]

It should be noted that my concern about whether there is ACTUALLY any significant time saving to come from what we've been asking for (the ClearScreen -1 request, anyway) is this text from the help file:

When SHOWSCREEN is called, the Back Buffer and Primary Surface are swapped. The now unusable Back Buffer will be replaced (cleaned) with the Offscreen Surface which is black when no bitmap is loaded.

...

If you don't see any result from your program, the first thing to check is whether you have forgotten to add the 'SHOWSCREEN' command to it.
Think of Double Buffering as two sheets of paper, one on top of the other where you draw on the bottom sheet. Once you're finished drawing, you swap the sheets and in the process erase the new bottom sheet. This hides the actual drawing of the sheet from the user and in the process eliminates screen flicker.

Now it CAN be dangerous to read too much from small words or even sentences, but there is an implication that the BackBuffer and FrontBuffer are somehow "swapped" rather than just copying the BackBuffer over the FrontBuffer. If indeed the BackBuffer is "simply" copied onto the FrontBuffer then there is much more room for a "ClearScreen -1" type command to save significant time for certain types of App. It would certainly help some aspects of code I have been writing, which is more vector-based than sprite-based, and would benefit from being able to display tiny single-triangle updates more quickly. Of course, being able to draw directly onto the FrontBuffer would be better still for MY code - but it seems this is not possible in GLBasic for multi-platform compatability reasons.

[Cliff3D]

Here's an improved (more accurate) version of the earlier flowcharts. It should be noted, however, that the "Copy backImage over BackBuffer" process and the "Clear BackBuffer" process MIGHT actually be the same process, but "Clear BackBuffer" simply uses an all-black background image to perform the "clearing" operation (this seems fairly likely given some of the wording in the help file).

[attachment deleted by admin]