BufferStrategy & accelerated memory

Java 2D
#1

I use a big VolatileImage to pre-render the static background of my game, and this image is painted onto a 2-buffer BufferStrategy since this improves performance (on windows the FPS nearly doubled).

Strangely though, on some computers the VolatileImage seems to be unaccelerated but the BufferStrategy is. When this happens the FPS is only about 11 when on most computers it is 70 (This must be because it takes ages to paint the unaccelerated VolatileImage to the BufferStrategy). I also get the following results:

bufferStrategy.getCapabilities().getFrontBufferCapabilities().isAccelerated() returns true
bufferStrategy.getCapabilities().getBackBufferCapabilities().isAccelerated() returns true
GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getAvailableAcceleratedMemory() returns 0 before and after I create the BufferStrategy or the big VolatileImage.

I assume that the VolatileImage is not accelerated since there is no accelerated memory, but why then is the BufferStrategy accelerated?
Thanks

#2

Hm. I thin kthats a question fior the AWT guys. Hopefully Dmitri or someoen like that will answer you…

#3

Thanks Jeff, I’ll post it in the javadesktop.org forums then and let people know the outcome.

#4

What java version are you seeing this on? Also, what OS/video board?
Is this full-screen or windowed application

I could imagine a situation where buffer strategy takes all available video memory so there’s not enough
left for a large volatile image…

Thanks,
Dmitri

#5

Many thanks Dmitri,

java 1.5.0_05, windows XP, window mode.
I don’t know what video card it is but I assume that it is a cheap variety since these are university computers.

Also,
bigVolatileImage.getCapabilities().isAccelerated() returns false
bigVolatileImage.getCapabilities().isTrueVolatile() returns false
bufferStrategy.getCapabilities().getFrontBufferCapabilities().isTrueVolatile() returns false
bufferStrategy.getCapabilities().getBackBufferCapabilities().isTrueVolatile() returns false

But from the very beginning the available accelerated memory is zero. So how can the BufferStrategy be accelerated or are its capabilities just saying the wrong thing?

#6

Um, I’m a bit confused.

Earlier you said:

And later in your last post you said:

Notice the difference in BS’s caps.

We’ve fixed some capabilities-related bugs in mustang, this may be one of them. Could you try
your test on Mustang?

Thanks,
Dmitri

#7

I don’t see a difference in what I posted, I think that I’ve just confused things by posting the capabilities of the big VolatileImage as well as the BufferStrategy. Let me straighten it out.

For the big VolatileImage:
bigVolatileImage.getCapabilities().isAccelerated() returns false
bigVolatileImage.getCapabilities().isTrueVolatile() returns false

For the BufferStrategy:
bufferStrategy.getCapabilities().getFrontBufferCapabilities().isAccelerated() returns true
bufferStrategy.getCapabilities().getBackBufferCapabilities().isAccelerated() returns true
bufferStrategy.getCapabilities().getFrontBufferCapabilities().isTrueVolatile() returns false
bufferStrategy.getCapabilities().getBackBufferCapabilities().isTrueVolatile() returns false

And:
GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getAvailableAcceleratedMemory() returns 0 before and after I create the BufferStrategy or the big VolatileImage.

We’ve fixed some capabilities-related bugs in mustang, this may be one of them. Could you try
your test on Mustang?
I’ll try that on the next problematic computer that I can. It would make sense if the BufferStrategy’s BufferCapabilities are returning false values.

Thanks for your help, its great that you and the rest of the Sun team take such an interest!

#8

Sorry, my bad. Too much (or little) coffee.

This looks like a bug. Or, rather, a manifestation of a long-standing bug
which is that unfortunately we ignore the capabilities for Blit BufferStrategy.

By default we’re trying to create an accelerated BS (with both front and
back-buffer accelerated). But if they for some reason end up not accelerated,
we don’t throw an exception as we should. I’ll file a bug if we don’t have it
already.

BTW, it looks like on your systems you’re running with DirectDraw acceleration
disabled for one reason or another. Thus the 0 as amount of video memory.

Thank you,
Dmitri

#9

Thanks for getting to the bottom of it. I just looked up how to test windows DirectDraw & Direct3D - run dxdiag.exe (http://support.microsoft.com/kb/191660). My system runs fine but my uni’s computers must have it disabled, I’ll ask them about it.

Thanks,
Keith