Remove..

Remove…

BufferStrategy uses VolatileImage in the background.
The only difference between BufferStrategy and manually creating the VolatileImage is that BufferStrategy uses page flipping, which means it changes the video pointer. When you use a VolatileImage, you have to manually call drawImage, which is called page blitting, or copying the data to the screen.
With both you have to check if the image is lost or restored so you have to follow the way the Javadoc says you should do.

To answer your question: BufferStrategy is the recommended option because page flipping is faster than page blitting.
Regarding your issue, what do you mean there is a huge delay? What is showing while the applet has disappeared?

Remove…

The Javadoc for VolatileImage explains when it can be lost and what happens when a window is resized.

In short, anything caused by the OS or other applications could make the the image in VRAM be lost.
When the window is resized, all buffers have to be re-created in the new size. This causes some slow down since the existing buffers have to invalidated and flushed, then the new ones have to allocated.

Remove…

I have no clue why the CPU would jump to 100% when resizing. Maybe something else in applet is consuming the CPU while resizing?

No matter the reason, BufferStrategy is still the more recommended way to go since it controls the VolatileImage and makes it easy to check if the image is lost or restored. It also, as I said earlier, does page flipping, which will greatly improve your graphics performance.

This may be irrelevant and I may be wrong but if your trying to use double buffering wouldn’t you call createBufferStrategy(2) on a canvas, or use 2 for however your creating the buffer strategy? Again I’m not sure if that’s correct or if it would have any effect.

I don’t believe that has any effect but yeah createBufferStrategy(2) is double buffering, createBufferStrategy(3) is triple buffering :wink: