Double-Buffering Without drawImage?

[Lash Rambo]

Is is possible to do away with the drawImage(offscreenImage) step of
double-buffering in Java?

Specifically, what I'm thinking of is two graphics contexts that can be
toggled between. One graphics context will be off-screen and drawn to,
while the other is on-screen and left alone. When the drawing is done and
it's time to present a new frame, simply swap the two graphics contexts's
references. In other words, the graphics context that was the off-screen
one becomes the on-screen one, and vice versa.

Is this possible, for instance, with java.applet.Applet? If so, it'd seem
to eliminate a lot of overhead, particularly for large scenes that need to
be completely redrawn each frame.

 

[William Brogden]

Is is possible to do away with the drawImage(offscreenImage) step of
double-buffering in Java?

Specifically, what I'm thinking of is two graphics contexts that can be
toggled between. One graphics context will be off-screen and drawn to,
while the other is on-screen and left alone. When the drawing is done
and
it's time to present a new frame, simply swap the two graphics contexts's
references. In other words, the graphics context that was the off-screen
one becomes the on-screen one, and vice versa.

Is this possible, for instance, with java.applet.Applet? If so, it'd
seem
to eliminate a lot of overhead, particularly for large scenes that need
to
be completely redrawn each frame.

You seem to be applying the "Graphics Context" idea exported
from another language. In Java, it does NOT imply a chunk of
memory you can "simply swap"

Bill

 

[Ryan Stewart]

Is is possible to do away with the drawImage(offscreenImage) step of
double-buffering in Java?

Specifically, what I'm thinking of is two graphics contexts that can be
toggled between. One graphics context will be off-screen and drawn to,
while the other is on-screen and left alone. When the drawing is done and
it's time to present a new frame, simply swap the two graphics contexts's
references. In other words, the graphics context that was the off-screen
one becomes the on-screen one, and vice versa.

Is this possible, for instance, with java.applet.Applet? If so, it'd seem
to eliminate a lot of overhead, particularly for large scenes that need to
be completely redrawn each frame.

You want page flipping. Have a look at the createBufferStrategy and
getBufferStrategy methods of java.awt.Window. A caution: the book I read
about it said that there were occasional problems calling getBufferStrategy
immediately after createBufferStrategy. It recommended trying the get every
20 ms or so in a loop until it is successful or a couple of seconds has
passed (in which case throw an Exception and exit).

 

[Lash Rambo]

You want page flipping. Have a look at the createBufferStrategy and
getBufferStrategy methods of java.awt.Window. A caution: the book I
read about it said that there were occasional problems calling
getBufferStrategy immediately after createBufferStrategy. It
recommended trying the get every 20 ms or so in a loop until it is
successful or a couple of seconds has passed (in which case throw an
Exception and exit).

Yes! That's exactly what I was looking for. Not sure if it will work
the way I think it will, but it looks promising. Thanks, Ryan!

 

[Guest]

Is is possible to do away with the drawImage(offscreenImage) step of
double-buffering in Java?

Specifically, what I'm thinking of is two graphics contexts that can be
toggled between. One graphics context will be off-screen and drawn to,
while the other is on-screen and left alone. When the drawing is done and
it's time to present a new frame, simply swap the two graphics contexts's
references. In other words, the graphics context that was the off-screen
one becomes the on-screen one, and vice versa.

Is this possible, for instance, with java.applet.Applet? If so, it'd seem
to eliminate a lot of overhead, particularly for large scenes that need to
be completely redrawn each frame.

If you're not limited to AWT, and can use Swing, I think you get
double buffering "for free"; i.e., extend javax.swing.JPanel, override
paintComponent() to do your painting, and allow Swing to handle all
the double buffering details for you. With luck, Swing is already
designed to leverage the most efficient kind of double buffering
available to the underlying platform (whether that be bit blitting
from main memory, or from graphics memory, or page flipping, or
whatever).

 

[Lash Rambo]

(e-mail address removed) wrote in

If you're not limited to AWT, and can use Swing, I think you get
double buffering "for free"; i.e., extend javax.swing.JPanel, override
paintComponent() to do your painting, and allow Swing to handle all
the double buffering details for you. With luck, Swing is already
designed to leverage the most efficient kind of double buffering
available to the underlying platform (whether that be bit blitting
from main memory, or from graphics memory, or page flipping, or
whatever).

Alright, I'll research this, as well. It'd certainly make things a lot
easier!