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 bs.show() 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?
[Message sent by forum member 'stolsvik' (stolsvik)]
http://forums.java.net/jive/thread.jspa?messageID=299367
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
