JDK-5104393 : Provide d3d pipeline to improve runtime performance of Swing/2D
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_nt,windows_xp
  • CPU: generic,x86
  • Submitted: 2004-09-20
  • Updated: 2005-11-21
  • Resolved: 2005-04-18
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 b33Fixed
Related Reports
Duplicate :  
JDK-5090195 - Windows: enabled texture glyph caching using Direct3D for improved performance
Duplicate :  
JDK-6214921 - WindowsXP L&F is no longer acceleratable (after the fix for 5106661)
Relates :  
JDK-6213204 - Starting any java program causes the screen to become blurred
Relates :  
JDK-6252147 - D3D: minimize device state changes in the pipeline
Description
Currently our use of Direct3D is minimal: by default
we only accelerate rendering non v/h lines, rectangles,
polygons.

We should be able to accelerate more primitives, 
transforms, alpha compositing, glyph caching (which
will enable accelerated AA-text rendering).

###@###.### 2004-09-20

###@###.### 2005-04-09 00:33:01 GMT
Comments
EVALUATION The initial implementation of the pipeline has been completed. Currently it's disabled by default pending resolution of some quality issues on some video boards. To enabled, supply -Dsun.java2d.d3d=true property to the vm. At this point the following primitives are accelerated by the D3D pipeline: - managed image to VolatileImage blits/transforms/scaling, w/ and w/o alpha compositing, nearest neighbor and bilinear filtering - D3DRenderer: - draw[Line, Rect, Poly*], FillRect - directly via DrawPrimitive for thin stroke and single color - the rest is implemented via FillSpans - MaskFill (AA fills) - Text rendering (AA/no AA): done via texture mapping, with a glyph cache - hardware clipping via stencil buffer Note: - Xor paint mode is not accelerated (our GDI pipeline is used as a fallback). - no gradient paint acceleration At the time of the initial putback, the following performance improvement were registered: Performance gains vary with benchmarks (data for Radeon 9800 Pro on WinXP): NinJo (mostly lines, polygon fills/draws), in milliseconds: nod3d (d3d disabled): 352021 ms d3d (d3d enabled ): 85933 ms ogl (ogl enabled ): 84176 ms FireStarter: (TR-transformed, AC-AlphaComposited, tr - translucent source image, op - opaque, bm - bitmask), number of rocks: TR+AC: AC: TR: no AC/TR: old dd/d3d 1 4300 1 4600(tr) 1300(op/bm) new d3d 3000 4500 3300 4500(tr/bm) 5300(opaque) J2DBench results for most accelerated primitives: http://javaweb.sfbay/~tdv/bugs/d3d_pipeline/benchmarks/2005-03-15_20h47m/j2dbench/Summary_Report.html In general, it's a win for most primitives, huge in some cases, especially when compositing or transformations are involved. Swingmark is currently about 15% slower with the new pipeline for ocean look and feel. Here are some swingmark data logs for those interested. (scroll to the bottom, look at the 'Mean'. 'target0' is the new pipeline, 'base' is jdk1.6.0): http://javaweb.sfbay/~tdv/bugs/d3d_pipeline/benchmarks/2005-03-15_20h47m/swingmark/swingmark.run.log (full logs can be found in the same directory) Note that some followup work considerably improved performance of Swing applications and the SwingMark scores. For more details see bug: 6252147: D3D: minimize device state changes in the pipeline ###@###.### 2005-04-09 00:33:01 GMT
09-04-2005