Skip to main content

How to request a Flip BufferStrategy?

4 replies [Last post]
stolsvik
Offline
Joined: 2006-09-17

One requests a specific BufferStrategy like this:

[Window|Canvas].createBufferStrategy(int numBuffers,
BufferCapabilities caps)

How do I make a caps object that state that ANY flip-strategy is good, but just fail if there is no flip possible?

Do I have to test with all of BACKGROUND, PRIOR, COPIED and UNDEFINED? Or is UNDEFINED the "any" or "fastest" when requesting? See, if a given setup can handle all of them, but one is faster than the other, I'd like that..

Btw, will both "Accelerated" and "TrueVolatile" be true for all flip-style BufferStrategies' ImageCapabilities?

Actually - I'd just like a method that gives me "the fastest, multibuffering, non-tearing graphics possible", whether or not that is volatile or accelerated or whatever. I guess one will have to make a testing-stage in the application, timing every single combination and picking the fastest.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Dmitri Trembovetski

java2d@JAVADESKTOP.ORG wrote:
> One requests a specific BufferStrategy like this:
>
> [Window|Canvas].createBufferStrategy(int numBuffers,
> BufferCapabilities caps)
>
> How do I make a caps object that state that ANY flip-strategy is good, but just fail if there is no flip possible?

You can do it like this:
try {
createBufferStrategy(2, new BufferCaps(true, true, FlipContents.UNDEFINED));
} catch (AWTException e){
// flip is unavailable, create the best you have
createBufferStrategy(2);
}

This way if flipping bs (ugh, that didn't come out right) is available
you'll get, otherwise you'll get something we think is the best
under these conditions.

> Do I have to test with all of BACKGROUND, PRIOR, COPIED and UNDEFINED? Or is UNDEFINED the "any" or "fastest" when requesting? See, if a given setup can handle all of them, but one is faster than the other, I'd like that..
>
> Btw, will both "Accelerated" and "TrueVolatile" be true for all flip-style BufferStrategies' ImageCapabilities?
>
> Actually - I'd just like a method that gives me "the fastest, multibuffering, non-tearing graphics possible", whether or not that is volatile or accelerated or whatever. I guess one will have to make a testing-stage in the application, timing every single combination and picking the fastest.

createBufferStrategy(2) with no parameters will generally be the best.
The only thing is that currently there's no simple way to request
a 'tear-free' (v-sync-ed) buffer strategy in Windowed mode.

We'll add public API for that in 7 hopefully.

Thanks,
Dmitri

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

stolsvik
Offline
Joined: 2006-09-17

> java2d@JAVADESKTOP.ORG wrote:
> > One requests a specific BufferStrategy like this:
> >
> > [Window|Canvas].createBufferStrategy(int
> numBuffers,
> > BufferCapabilities
> caps)
> >
> > How do I make a caps object that state that ANY
> flip-strategy is good, but just fail if there is no
> flip possible?
>
> You can do it like this:
> try {
> createBufferStrategy(2, new BufferCaps(true,
> true, FlipContents.UNDEFINED));
> } catch (AWTException e){
> // flip is unavailable, create the best you have
> createBufferStrategy(2);
> }
> This way if flipping bs (ugh, that didn't come out
> right) is available
> you'll get, otherwise you'll get something we think
> is the best
> under these conditions.

Okay, so "UNDEFINED" is actually the "I don't care" option when requesting?

Also, I don't find that constructor taking "true, true" - only one taking two ImageCapabilities

> Btw, will both "Accelerated" and "TrueVolatile" be
> true for all flip-style BufferStrategies'
> ImageCapabilities?

You didn't answer the above.. Care to? (It would go into the pool of "nice to know - maybe it will be immensely useful at some point")

> createBufferStrategy(2) with no parameters will
> generally be the best.
> The only thing is that currently there's no simple
> way to request
> a 'tear-free' (v-sync-ed) buffer strategy in
> Windowed mode.
> We'll add public API for that in 7 hopefully.

Please do! And make things explicit. Make the BufferStrategy in Swing explicit. Basically, make Swing be an actual disjoint layer above AWT/Java2D, utilizing ONLY the public, userfacing APIs of AWT/Java2D to work (I don't really know how far from that it is at this point - but I still feel there are some magic involved..)

Dmitri Trembovetski

java2d@JAVADESKTOP.ORG wrote:
>> This way if flipping bs (ugh, that didn't come out
>> right) is available
>> you'll get, otherwise you'll get something we think
>> is the best
>> under these conditions.
>
> Okay, so "UNDEFINED" is actually the "I don't care" option when requesting?

No, it says that you don't care about the contents of the
buffer after the flipping, which corresponds to the "flip" buffer
change mode in both Direct3D and OpenGL.
I know, it's not super-intuitive.

> Also, I don't find that constructor taking "true, true" - only one taking two ImageCapabilities

Well, you get the idea, I hope. 'true' -> 'new ImageCap(true)'.

>> Btw, will both "Accelerated" and "TrueVolatile" be
>> true for all flip-style BufferStrategies'
>> ImageCapabilities?
>
> You didn't answer the above.. Care to? (It would go into the pool of "nice to know - maybe it will be immensely useful at some point")

I don't see a situation in which this knowledge would
be of immense value, but yeah, I believe for flip
strategies IC will be 'accelerated' and 'true volatile'.

>> createBufferStrategy(2) with no parameters will
>> generally be the best.
>> The only thing is that currently there's no simple
>> way to request
>> a 'tear-free' (v-sync-ed) buffer strategy in
>> Windowed mode.
>> We'll add public API for that in 7 hopefully.
>
> Please do!

> And make things explicit. Make the BufferStrategy in Swing explicit. Basically, make Swing be an actual disjoint layer above AWT/Java2D, utilizing ONLY the public, userfacing APIs of AWT/Java2D to work (I don't really
know how far from that it is at this point - but I still feel there are some magic involved..)

I doubt this will happen. Whether or not swing uses buffer strategy
underneath is an implementation detail you shouldn't care about.
There's tons of technical reasons why this can be done anyway.

Thanks,
Dmitri

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

stolsvik
Offline
Joined: 2006-09-17

> > And make things explicit. Make the BufferStrategy
> in Swing explicit. Basically, make Swing be an
> actual disjoint layer above AWT/Java2D, utilizing
> ONLY the public, userfacing APIs of AWT/Java2D to
> work (I don't really
> now how far from that it is at this point - but I
> still feel there are some magic involved..)
>
> I doubt this will happen. Whether or not swing
> uses buffer strategy
> underneath is an implementation detail you
> shouldn't care about.
> There's tons of technical reasons why this can be
> done anyway.

I guess you meant "can't"?

Could you share one or two of these technical reasons? See, given only AWT and Java2D, I can't seem to grok why it wouldn't be possible to implement a complete "pixeling" widget toolkit aka Swing that does not utilize the underlying windowing system except for lower level primitives like window/canvas/frame and painting? Why would one _need_ tricks beyond the public-facing APIs from AWT and Java2D to make Swing? Wouldn't such a separation make for easier to understand APIs, where Swing was just an application using the sole graphical interface to the host (AWT/Java2D) that Java provides?

I do understand that the latter are philosophical questions, at least at this point. But any light shed would be very nice.

Thanks a lot,
Endre.