-
Bug
-
Resolution: Won't Fix
-
P4
-
None
-
5.0
-
None
-
generic
-
solaris_9
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
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
- relates to
-
JDK-4967886 Swing should provide full double buffering per window
-
- Resolved
-