About multiple buffers when using BufferStrategy

[Seb]

I would like to know what reason there is to support more than a single back buffer when using a bufferstrategy.

As far as I know this has 2 uses, both of which are apparently not possible with the API as it stands.

The first use is, when using 3 buffers, to have the first buffer (the primary surface)  being displayed, the second buffer ready and waiting for the vertical retrace so that it can appear next, and the third buffer being drawn on.
This can't be done in Java since there's no way to intercept the retrace, and show() is not syncronized with the retrace either.

The second use is to draw on as many buffers as we can and optimally do PAGE FLIPPING between them, another impossibility since apparently we can only access one buffer at a time.

The last line of this tutorial: http://java.sun.com/docs/books/tutorial/extra/fullscreen/bufferstrategy.html, states that 'It may be end up being wasteful to use more than one back buffer. Multi-buffering is only useful when the drawing time exceeds the time spent to do a show. Profile your application.'

But that's no real use for multiple buffers. As it says in the tutorial, one should think about optimizing if it gets to that, specially for games.

I know there's a gaming API being developed by Sun, but they should think about adding this functionality to BufferStrategy since that's where it belongs.

Any comments on this? I'm mostly curious as to why they would add this functionality if it's mostly useless as it is. Maybe there's another use and I'm missing something.

Seb

[Seb]

Allright, I just found Jeff's article on image types in java posted on this site thanks to google.

In there he does state that show() is scan synchronized, which is the only place where I found this documented, but I'm left wondering how the synching works.
1. Does it return immediattely or does it return after the retrace?
3. If it returns immediately, what happens to subsequent .getDrawGraphics() calls before the retrace? Do they return the same back buffer?

I think I could figure out the third one experimenting a bit. My little scroller tilemap test (it's quite evolved now, I'll post a .jar somewhere when it's more useful) drops from 128 to 60 fps when I implement page flipping. This is what hinted me about the vertical retrace synching. It also seems that show() makes the thread sleep, and that's why I only get 60 fps now.

Jeff, can you expand on the inner workings of this a bit cause I'm just guessing.

Seb

[chet]

I'm not sure which of your multiple questions to respond to, but I'll maybe summarize your posts as "What the heck is up with BufferStrategy?" and try to answer that catch-all...

BufferStrategy _is_ synchronized to the retrace when you are doing page-flipping.  Way deep in the internals of Java2D on Windows, we implement show() as a ddraw Flip() command with the flag DDFLIP_WAIT.  This means that (a) the flip command will wait for the vertical refresh to occur and (b) we will wait for the Flip command to process before we return from the show() call.  Make sense?

Note that the same is not true for non-page-flipping BufferStrategy classes; if you are in windowed mode, you will probably end up using a BltBufferStrategy, which simply uses a ddraw Blt command (on Windows, of course) to copy to the screen.  That command is not sync'd to the vertical retrace, so show() will return as soon as we've sent off the Blt command.

Your guess about vertical retrace being linked to the 60 fps is correct; since you are now waiting for the Flip to occur, your frame rate is maxed at the current refresh rate.

If your code is simply waiting for the show() command to return, that is one place where triple buffering _might_ help; if you had a third buffer available, then show() would return immediately and you could start drawing on the free buffer.  But it's not always a win; if you are drawing much faster than the frame rate, then you will simply get one frame ahead and sit there waiting for the following show() to return.

My explanations are Windows-specific, but the same should be true on any platform that support page-flipping.

Hope that helps...

Chet.

Games published by our own members! Check 'em out!

[swpalmer]

Is it not possible for BltBufferStrategy to sync to the vertical retrace?

Having animations in a window that have a big tear line through the middle kinda stinks.

It seems to me that this should be possible and that if it is possible it is also desirable.  What's the deal?

[chet]

Unfortunately, it is not possible to sync while using Blt.  This is simply a hole in the API.  The capability exists on some platforms to allow it, but there is no way to access it through the current BufferStrategy (or other class) methods.

This is something we should add for jdk1.5...

[Seb]

thanks chet,

that pretty much takes care of my doubts. Although, as you said yourself, there are some holes in the API, it's pretty workable as it is, I just needed to know how it worked, there isn't that much documentation on this.

Seb.

PD: I still miss interrupts!