BufferedStrategy.getFlipContents().....woot?

Java 2D
#1

I was profiling my engine a bit and found out something weird…


BufferCapabilities bc=gc.getBufferCapabilities();
            if(bc.isPageFlipping() && bc.getFlipContents()==BufferCapabilities.FlipContents.PRIOR){
            	window.createBufferStrategy(2,new BufferCapabilities(
                    				new ImageCapabilities(true),
                    				new ImageCapabilities(true),
                    				BufferCapabilities.FlipContents.PRIOR));
            	System.out.println("prior");
            }

I m creating bufferstrategy on my fullscreen awt frame. As far as i know this code is good…correct me if i m wrong.Still profiling resluts werent nice(cpu usage was like 90%).Then i just messed with the code and changed the line

BufferCapabilities.FlipContents.PRIOR));

to

BufferCapabilities.FlipContents.COPIED));

. The results were really unexpected-cpu usage was below 15%?!??!?!?!?
Can any1 explain how is this possible?I mean i can understand that bliting may be faster in the case of my comp, but damn method getFlipContents returned prior…:S
Computer is laptop 1.4ghz celeron,768 ram, integrated graphics card.
Tnx in advance.

#2

Hmm…i thought that somebody might answer…
Anyway does any1 think that this might be a bug?It may need more atention…

#3

I wouldn’t be surprised that your video card doesn’t have VRAM (use of shared memory) so it wouldn’t be able to do true page flipping. The COPY method might then be faster? Just a thought.

#4

Sure, but how come performance degrades soo much? Besides getFlipContents returned Prior-i guess that it is supposed to know things about hardware it is working on.
Weird thing is that tutorial says that u should create the bufferstrategy with the same flipcontents as this method returned(or have i misunderstood)…

#5

Check the result of ImageCapabilities.isTrueVolatile() of the BufferCapabilities. It should return false if you don’t have VRAM.

#6

OK, i ve tried that. The code:


 bs=window.getBufferStrategy();
 System.out.println(bs.getCapabilities().getFrontBufferCapabilities().isAccelerated()+" "+bs.getCapabilities().getFrontBufferCapabilities().isTrueVolatile());

gives true for acceleration and false for true volatile. I mean, i knew this since my laptop uses shared ram for vram… still what about that true answer for acceleration(since there is no vram)?
And the main question still remains, but is a bit unchaged: when i get prior as flipcontent, should i always check for that volatile support you directed me to? I guess that in that kind of situation flipcontents.COPIED is better…

And…still why so much performance penalty when using prior? What happens then under the hood?

#7

As far as I know the application does not see any difference between “true” and “shared” VRAM, also shared vram can be volatile as its the case with “real” VRAM. This has nothing to do with the RAM implementation but rather how the driver handles memory. However as I said this is all “as far as I know” … so don’t beat me if I’m wrong :wink:

lg Clemens

#8

Slux,

I think your question is one for a J2D developper at sun such as Dimitri Trembovetsky.

#9

Sure i would like to get an answer from some1 like him…
I pmed mr Trembovetski…waiting now…i guess that he has much to do :wink:

#10

The short answer is that the capabilities for BufferStrategy is messed up.

Dmitri

#11

Err…is it a bug? Really short answer :stuck_out_tongue:

Can i do anything to detect it(api supported)?

#12

Yeah it’s a bug with BufferCapabilities, Dmitri’s helped me with it before before:

http://www.java-gaming.org/forums/index.php?topic=13604.0

Not sure if its fixed in Java 6. Good luck,

Keith

PS: Why are you dealing with BufferCapabilities.FlipContents.PRIOR, etc ? I’ve never gone into that stuff in detail but am interested…

#13

Honestly…well, i ve read it in a tutorial…like its better to build BufferStrategy with capabilities supported with ur hardware than to just call createBufferStrategy(n)-maybe i m wrong, correct me then.
In capabilities u set desired acceleration for front and back buffer, and kind of flipping method-prior usualy points that real page flip occures…
Maybe i havent understood this correctly and there is no need to mess with capabilities…though i think that it is required for maxed performance…