JDK-6255507 : OGL: use GL_EXT_framebuffer_object extension for improved performance
  • Type: Enhancement
  • Status: Resolved
  • Resolution: Fixed
  • Component: client-libs
  • Sub-Component: 2d
  • Priority: P4
  • Affected Version: 5.0
  • OS: solaris_9
  • CPU: generic
  • Submit Date: 2005-04-14
  • Updated Date: 2017-05-16
  • Resolved Date: 2005-09-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availabitlity Release.

To download the current JDK release, click here.
6 b51Resolved
Related Reports
Relates :  
Relates :  
The new GL_EXT_framebuffer_extension is essentially a platform-independent
replacement for pbuffer and render-to-texture functionality.  It allows
for true render-to-texture functionality without the large VRAM footprint
requirements of pbuffers.  For example, one can create a framebuffer object
(FBO) with only a 32-bit color buffer and attach a stencil buffer only when
it is needed.  So for apps that don't make use of complex clipping, we could
probably avoid creating a stencil buffer, which would cut down on VRAM usage.
Currently, we would need to create a pbuffer to get the same functionality,
but typically the windowing system will allocate buffers that Java 2D doesn't
need, such as a backbuffer, depth buffer, accum buffers, and so on.
(Pbuffers can sometimes require as much as 192 bits per pixel, so the savings
with FBOs are obvious.)

Even better, one can render to an FBO without switching contexts (calling
MakeCurrent() over and over can be costly).  Currently, context switching
overhead makes Swing rendering slower when OGL is enabled.  This is because
Swing will render a couple things into their backbuffer (a pbuffer), copy
the pbuffer to the screen, and repeat.  Each time we switch the context
from the pbuffer to the screen and back to the pbuffer, we incur significant
overhead.  This overhead can be avoided (or at least minimized) when using
the FBO extension.
###@###.### 2005-04-14 19:32:11 GMT

EVALUATION FBO support is now in mainstream drivers from both Nvidia (as of 76.64 on Linux and Solaris, 77.77 on Windows) and ATI (as of 5.7 on Windows). We will now use FBOs instead of pbuffers as the accelerated surface for VolatileImages, but only if the following conditions are met: - the GL_EXT_framebuffer_object extension is present (obviously) - the new sun.java2d.opengl.fbobject system property is set to "true" (off by default) - we are able to create an FBO with the appropriate attachments The reason this will be disabled by default (at least for the near future) is that there are still some kinks in the drivers. For example, both Nvidia and ATI do not yet support stencil attachments for FBOs, which is why I've filed 6313838 (and plan to fix it very soon), so that we eliminate our dependency on stencil buffers. Also, on Nvidia drivers, copyArea() is very slow for FBO destinations (very similar to the bug reported in 6298243), which results in slow scrolling when FBO support is enabled. It looks like Nvidia will be addressing that issue in an upcoming driver release. Once the above issues are resolved, we can consider turning on FBO support by default.

EVALUATION Beta drivers that include support for the FBO extension are just now becoming available (e.g. the 7590 beta drivers for Linux from Nvidia support it). Nvidia claims that context switching performance is improved by 2x with FBO. An initial experiment on my Nvidia GF FX 5600 shows a 14% improvement in SwingMark scores when using FBOs instead of pbuffers. ###@###.### 2005-04-14 19:32:11 GMT