Skip to main content

About BltBufferStrategy

1 reply [Last post]
Joined: 2006-09-17

Reading the javadoc of BufferStrategy regarding blitting, and reading the source of Component.BltBufferStrategy, I can't help being a bit puzzled:

Why would one want the buffers (assuming more than 2) "copied, or blitted forward in a chain"? This obviously requires as many copy-actions as there are buffers on every .show() invocation.

Wouldn't it be better to, in effect, keep two integers: one which points to the "show buffer" and one that points to the "draw buffer"? Upon .show(), the current draw one becomes the show, and one picks a new available draw. Of course, one just keeps one integer, and the current draw is always the one directly behind the current show.

However, unless there are some internal magic involved with the BltBufferStrategy, it seems meaningless to have more than one backbuffer at any rate. This is because the drawing of the backbuffer into the frontbuffer seems to be synchronous, and hence as show() returns, one could just start drawing into the same backbuffer again. I can't seem to being able to construct a reason for having more than one backbuffer unless it is because one then can have one buffer that is being shown, one (or possibly several) that are ready to be shown at next retrace, and one that is being drawn into. So, if there is no asyncronousness, which typically would be waiting for the retrace (vsync) before flipping or blitting, there should be no need for more than one backbuffer?

(As an aside, I think BltBufferStrategy should rather have been called CopyBufferStrategy, but I guess that's somewhat subjective.)

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2006-09-17

I'm experimenting with BufferStrategy. I can run both my screens in full screen exclusive, both vsynching. That is nice.

I'm however experiencing some extremely strange timings, and I wonder if some light can be shed on this.

I first believed that waits for retrace, locking the entire graphics system while this waiting happens. This because the wait() is using the most time. I soon realized that this is obviously the case when the drawing time is less than 1/60 second, as the refresh on my monitor is 60Hz - there aren't enough backbuffers then, and it will halt until the retrace is done and the current show-buffer is freed to begin drawing into. But what puzzles me, is that show() is still the most time-consuming operation when the total time between each invocation goes above 16.667 ms, and that this time is proportional with the amount of copies drawn.

I've thus begun wondering whether the new graphics system somehow /schedules/ drawing operations into some pipe, even for VolatileImages, so that my drawing-a-whole-lot-of-copies-of-an-image method return *before* the actual pixels are in place on the destination. The invocation of show() would in that case "flush" this pipeline (as would probably any g.drawImage(someVolatileImage));

I find this rather strange, but this explanation would also cover why I can't seem to get past the flush()-operation's timing by having the flush for each BufferStrategy going in separate threads, and trying to run the drawing thread into separate VolatileImages ("backbuffers"), being copied over into the BS when flush() has finished.

Any info?