question about an active rendering implementation

[skinny boy]

i was reading this ( http://www.gamedev.net/reference/programming/features/javarender/default.asp )

the code uses the graphics context of a BufferedImage, which is as big as the screen,
he draws on it,
and then uses the BufferStrategyClass.getDrawGraphics to acquire the graphics context of the buffer that the BufferStrategy uses

then the code draws the BufferedImage on the buffer

why not draw on the BufferStrategy buffer from the very beginning?

content lost issues??? (which might happen in case the rendering or gameLogic takes a lot of time)

[Karmington]

double buffering is based on drawing 'behind the scenes', and then flipping the complete image in one fell swoop to avoid flicker
unless i'm missing some nuance of the BufferStrategy itself?

[Abuse]

If you do what that tutorial is suggesting(draw onto a BufferedImage), you will never get hardware accelerated drawing.

Ignore that aspect of the tutorial, and draw direct to the Graphics context obtained from the BufferStrategy.

Seems like the author has mistakenly mixed the pre-BufferStrategy paradigm(Java 1.2-1.3), of using a BufferedImage as a back buffer, with the post-BufferStrategy paradigm (1.4+)

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

[skinny boy]

If you do what that tutorial is suggesting(draw onto a BufferedImage), you will never get hardware accelerated drawing.

Ignore that aspect of the tutorial, and draw direct to the Graphics context obtained from the BufferStrategy.

Seems like the author has mistakenly mixed the pre-BufferStrategy paradigm(Java 1.2-1.3), of using a BufferedImage as a back buffer, with the post-BufferStrategy paradigm (1.4+)

thats what i thought (about not having hardware accelaration)
though i am not so sure.... its the same as drawing my stuff to the graphics content of the BufferStrategy either straight up, or through an image
both manipulate the graphics context of the BufferStrategy, and i am not so sure that the drawing on a BufferedImage takes longer that drawing on the graphics context of the BufferStrategy

the BufferedStraegy uses VolatileImages (not so sure, have to recheck) for bufferes, so when you acquire the graphics context of a buffer which is currently not showing, i believe there is a chance that the speed of drawing on it is the same with the speed of drawing on a BufferedImage

the only difference (i think) is that if i use the BufferedImage, it needs one more step,,,,
which is useless (unless someone can find a reason why not)

any agrees/disagrees??

[ManaSink]

I used to do the two step process in the past because the graphics pipeline in 1.4 and 1.5 didn't support alpha blending for hardware accelerated images unless you added a command line parameter.   Hardware acceleration worked fine for opaque images, or bitmask (0% or 100% only) transparency, but translucent blends (50% like stained glass, shadows, fog, etc) had to be done on the heap, and the result blitted opaque as a second step.  I think the new VMs have accelerated alpha blending by default, so this may be a thing of the past.

BufferedImage WILL try to accelerate content, but any time you alter it's contents it gets flagged as dirty.  If you write to the image every frame, or access the backing pixel array, it will always be dirty, and always get copied from system memory to video memory (LAME).  If you avoid changing the image it will cache an  accelerated version in video memory.  I use this to avoid doing the really expensive stuff like scaling and rotating every frame.

If you are using the flip strategy on your BufferStrategy, it will block for the monitor vsync when you show it.  This will cap your framerate to the monitor hertz, typically 60 fps, and a small overrun on every frame would cut that in half waiting for the next vsync.  This does prevents tearing though, which pisses me off worse than a slower frame rate, but can surprise you if you don't expect it.

Hope that helps.   

[skinny boy]

no it didnt,, but while i was reading it (again and again in order to grasp it) i was also thinking about what i had posted...
and this is what i have thought

if BufferStrategy uses VolatileImages for buffers, (in http://209.85.229.132/search?q=cache:4XHeW8Aaji4J:java.sun.com/j2se/1.5.0/docs/api/java/awt/image/BufferStrategy.html+bufferstrategy+uses+volatile+image+for+buffer&cd=1&hl=en&ct=clnkit says "Since the buffers in a buffer strategy are usually type VolatileImage.." )
then the graphics content you acquire through the getDrawGraphics method is probably working directly to the VRAM, as a VolatileImage inhabits the VRAM and not system RAM....

am i correct?

[Abuse]

no it didnt,, but while i was reading it (again and again in order to grasp it) i was also thinking about what i had posted...
and this is what i have thought

if BufferStrategy uses VolatileImages for buffers, (in http://209.85.229.132/search?q=cache:4XHeW8Aaji4J:java.sun.com/j2se/1.5.0/docs/api/java/awt/image/BufferStrategy.html+bufferstrategy+uses+volatile+image+for+buffer&cd=1&hl=en&ct=clnkit says "Since the buffers in a buffer strategy are usually type VolatileImage.." )
then the graphics content you acquire through the getDrawGraphics method is probably working directly to the VRAM, as a VolatileImage inhabits the VRAM and not system RAM....

am i correct?

Yes. Thereby allowing the draw operations to be hardware accelerated.

BufferedImages on the other hand keep their primary surface in system RAM.

[skinny boy]

thank you for confirming my opinion

[ManaSink]

Sorry dude, didn't mean for my reply to be so hard to follow.   

As Abuse pointed out, rendering directly using the BufferStrategy will hardware accelerate the operations on a modern VM.
For Windows, a modern VM is 1.6u10+
http://java.sun.com/javase/6/webnotes/6u10.html

BufferedImages are "managed" by default.  "Managed" images are cached in VRAM when they are drawn.  If the image is later altered, the cached copy is discarded.  Since the example code alters the image every frame, a cached VRAM copy is never used.
http://java.sun.com/j2se/1.5.0/docs/guide/2d/new_features.html

This snippet draws a blue box in a random location each frame, and is NOT accelerated:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16

BufferedImage img = gc.createCompatibleImage( 640, 480 );  //whole screen buffer while (true){     Graphics gfx = img.getGraphics();     gfx.setColor(Color.BLACK);     gfx.fill(640,480);  //oops, image content altered..., VRAM cache discarded if present.    int x = rand.nextInt(256);     int y = rand.nextInt(256);     gfx.setColor(Color.BLUE);     gfx.fillRect(x,y,50,50);  //draw blue box in random location on large image    gfx.dispose();     Graphics bufGfx = bufferStrategy.getDrawGraphics();     bufGfx.drawImage(img,0,0,null);  //draw large image, always modified since last draw, must copy from system RAM to VRAM    bufGfx.dispose();     bufferStrategy.show();     // sleep, yield, etc... }

This snippet does the same, but uses BufferStrategy acceleration and BufferedImage caching:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16

BufferedImage img = gc.createCompatibleImage( 50,50 );  //small image of a blue box, so only 50x50. Graphics gfx = img.getGraphics(); gfx.setColor(Color.BLUE); gfx.fillRect(0,0,50,50);  //image is rendered only once. gfx.dispose(); while (true){     Graphics bufGfx = bufferStrategy.getDrawGraphics();     bufGfx.setColor(Color.BLACK);     bufGfx.fill(640,480);  // direct call on buffer, accelerated by DirectX or OpenGL    int x = rand.nextInt(256);     int y = rand.nextInt(256);     bufGfx.drawImage(img,x,y,null);  //draw small image at random location.  image not modified, so quick copy from VRAM is possible    bufGfx.dispose();     bufferStrategy.show();     // sleep, yield, etc... }

Admittedly, for just drawing a blue box, there isn't much value in caching the image.  I was just trying to show how to properly use a BufferedImage to take advantage of hardware acceleration.

manasink

[skinny boy]

i get it now, thank you for reposting