-
Bug
-
Resolution: Fixed
-
P4
-
5.0
After the single-threaded rendering changes (6219284) were integrated,
VolatileImage->VolatileImage performance is no longer optimal. In theory,
it should be possible to queue up any number of Pbuffer->OpenGLSurface
blit operations and execute them asynchronously. However, this is a common
case in the Swing repaint mechanism, so instead of waiting up to 100 ms
for the queue to be flushed automatically, we need to execute these
operations immediately; otherwise, it becomes a usability issue. For example,
if you click a JButton, we need to update the contents of the Swing
backbuffer and then copy to the screen immediately, or else there will be
a noticeable delay.
So with the STR changes, a simple check was added to OGLBlitLoops.IsoBlit()
which said "if the source is a pbuffer, flush the buffer immediately after
enqueuing the blit operation". This is really only necessary if the
source is a pbuffer and the destination is the screen (window); otherwise
if the destination is a pbuffer or backbuffer, we should be able to enqueue
any number of operations. This simple optimization should help Swing
rendering performance; for things like the Ocean gradients that are cached
in VolatileImages, we will no longer have to flush the queue each time
one of these cached images is rendered to the backbuffer. This will help
increase the number of operations that can be batched into a single
flushBuffer() downcall.
###@###.### 2005-03-15 08:21:15 GMT
VolatileImage->VolatileImage performance is no longer optimal. In theory,
it should be possible to queue up any number of Pbuffer->OpenGLSurface
blit operations and execute them asynchronously. However, this is a common
case in the Swing repaint mechanism, so instead of waiting up to 100 ms
for the queue to be flushed automatically, we need to execute these
operations immediately; otherwise, it becomes a usability issue. For example,
if you click a JButton, we need to update the contents of the Swing
backbuffer and then copy to the screen immediately, or else there will be
a noticeable delay.
So with the STR changes, a simple check was added to OGLBlitLoops.IsoBlit()
which said "if the source is a pbuffer, flush the buffer immediately after
enqueuing the blit operation". This is really only necessary if the
source is a pbuffer and the destination is the screen (window); otherwise
if the destination is a pbuffer or backbuffer, we should be able to enqueue
any number of operations. This simple optimization should help Swing
rendering performance; for things like the Ocean gradients that are cached
in VolatileImages, we will no longer have to flush the queue each time
one of these cached images is rendered to the backbuffer. This will help
increase the number of operations that can be batched into a single
flushBuffer() downcall.
###@###.### 2005-03-15 08:21:15 GMT