JDK-6278027 : OGL: enable bilinear rtt->surface transforms
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 5.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: generic
  • Submitted: 2005-05-31
  • Updated: 2008-02-05
  • Resolved: 2005-06-27
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 Availability Release.

To download the current JDK release, click here.
JDK 6
6 b43Fixed
Related Reports
Relates :  
JDK-4841762 - OGL: enable bilinear sw->surface transforms
Description
Currently in OGLDrawImage.renderImageXform(), we punt to the superclass (software-
based) implementation if BILINEAR interpolation is specified and the source
surface type is not OpenGLTexture.  This check prevents us from using our
OpenGLSurface->OpenGLSurface transform loops when BILINEAR is specified, because
those loops currently cannot handle bilinear properly (see 4841762).  However,
we should be able to handle bilinear OpenGLSurfaceRTT->OpenGLSurface transforms
because the source surface is essentially a texture, and bilinear texture->surface
transforms do work properly.
###@###.### 2005-05-31 07:23:46 GMT
Comments
EVALUATION All we need to do is slightly tweak the logic in OGLDrawImage.renderImageXform(), so instead of: if (... && (sData.getSurfaceType() == OGLSurfaceData.OpenGLTexture || interpType == AffineTransformOp.TYPE_NEAREST_NEIGHBOR)) we would have: if (... && (sData.getSurfaceType() == OGLSurfaceData.OpenGLTexture || sData.getSurfaceType() == OGLSurfaceData.OpenGLSurfaceRTT || interpType == AffineTransformOp.TYPE_NEAREST_NEIGHBOR)) Note that OpenGLSurfaceRTT is only used currently on Windows to denote a pbuffer (render-to-texture) surface. So for now this fix will make bilinear VolatileImage transforms faster only on Windows. On Linux/Solaris, things will improve when we fix 4841762. Also, the upcoming support for the GL_EXT_framebuffer_object extension (see 6255507) will mean that bilinear VolatileImage transforms will be similarly fast on all platforms that support that extension, since those surfaces will be marked as OpenGLSurfaceRTT (and therefore this fix will apply there as well). ###@###.### 2005-05-31 07:23:46 GMT As an example of the performance gains that this fix enables (on WinXP with an Nvidia GF FX 5600, 2x 2.6GHz P4) here are some J2DBench results: Options common across all tests: testname=graphics.imaging.tests.drawimagescaledown graphics.opts.xormode=false graphics.opts.renderhint=Quality graphics.opts.alpharule=SrcOver graphics.opts.extraalpha=false global.dest=VolatileImg graphics.imaging.src=volimg opaque graphics.opts.clip=false graphics.opts.anim=2 graphics.opts.sizes=20: nb: 87.22887911 (var=4.98%) (100.0%) new: 62841.55688 (var=1.25%) (72042.15%) graphics.opts.sizes=250: nb: 413.4125560 (var=0.65%) (100.0%) new: 301291.56821 (var=0.58%) (72879.15%) In other words, bilinear VI->VI transforms are about 720x faster on WinXP with this fix in place. ###@###.### 2005-05-31 23:45:13 GMT
31-05-2005