Bug ID: JDK-6226290 OGL: optimize FlipBufferStrategy/COPIED

Type: Bug
Component: client-libs
Sub-Component: 2d
Affected Version: 5.0

Priority: P4
Status: Closed
Resolution: Won't Fix
OS: solaris_9
CPU: generic

Submitted: 2005-02-07
Updated: 2010-04-02
Resolved: 2006-02-08

With 4967886, it becomes possible for the Swing backbuffer to live in the
OpenGL (hardware) backbuffer for a given window.  This is a great step forward
because we no longer have to allocate an expensive (both in terms of footprint
and performance) pbuffer for the Swing backbuffer.  Swing will be using
a BufferStrategy with FlipContents.COPIED (where available), so we should
optimize this case.

The major benefit of using COPIED is that it works very well with the Swing
rendering pattern of:
  - render to backbuffer
  - copy backbuffer to screen
  - rinse, repeat

Performance of a backbuffer to screen copy is much faster than a
comparable pbuffer to screen copy.  However, we can further optimize this
case by avoiding a context switch, since the underlying read/draw drawables
remain constant.
###@###.### 2005-2-07 19:15:25 GMT

EVALUATION As mentioned above, there was no noticeable benefit from optimizing this code path, and it would slightly complicate the code, so it's probably not worth pursuing further. While the FlipBS/COPIED case is interesting from a performance standpoint for Swing applications, it won't necessarily play well with the "gray rect" fix that was integrated in Mustang, since on most OpenGL implementations the hardware backbuffer is not persistent. So if you drag another window over a double-buffered OpenGL window, the hardware backbuffer of the obscured window may be clobbered, and since the "gray rect" fix relies on a persistent backbuffer, the FlipBS/COPIED approach won't work across the board for the OpenGL pipeline. And just to add a little more background, the original impetus for experimenting with Swing using FlipBS/COPIED was that it does not require an expensive OpenGL context switch to copy from the backbuffer to the screen. Also, footprint is reduced since we wouldn't require a VRAM-hungry pbuffer for the Swing backbuffer. But in Mustang we added support for the new GL_EXT_framebuffer_object extension, which addresses both of these issues: copying an FBO to the screen does not require context switching so it is very fast, and they are also efficient from a VRAM footprint standpoint, because we only attach the buffers that we need. Going forward, I think FBO gives us everything we need for a fast/efficient Swing backbuffer, so that's yet another reason for not pursuing the FlipBS/COPIED approach further (at least for the common case).

08-02-2006

EVALUATION When I experimented with these changes, I found that there was little improvement in performance for this case. We can still investigate fixing this in the future, but it's not crucial for Mustang, especially since we are not planning to use the FlipBufferStrategy approach for the gray rect fix anytime soon.

01-08-2005

EVALUATION The fix should be simple. If the validated read/draw drawables are the same as the given read/draw drawables, then we can avoid the expensive call to glXMakeContextCurrent() (or wglMakeCurrent(), in the Windows case). ###@###.### 2005-2-07 19:18:03 GMT

07-02-2005