JDK-6252147 : D3D: minimize device state changes in the pipeline
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2005-04-07
  • Updated: 2008-02-06
  • 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
Relates :  
Description
The current implementation of D3D pipeline does a lot more device state
changes than needed, which negatively affects performance, since
state changes could be very expensive.

###@###.### 2005-04-07 18:06:09 GMT

Comments
EVALUATION Don't reset the texture if not needed, don't change the texture stage states unless necessary. So we need to track the current device state, such that each operation supplies it's own operation type to BeginScene, which updates the state as necessary. Also, use a single vertex format for all DrawPrimitive calls. This fix yielded large performance gains. ###@###.### 2005-04-07 18:06:10 GMT With this fix the new D3D pipeline is within 1-2% in SwingMark. With AA enabled, it's consistently better by ~3%. It's still slower than with D3D completely disabled, by about 8% (mostly because of slower scrolling), but it's much better than before. In J2DBench, some text rendering benchmarks are ~120% faster than the non-d3d text pipe, for cases where use texture cache. Small image copies improved by ~20% over the initial D3D pipeline. For Firestarter, we get about 30% more rocks compared to initial D3D pipeline implementation putback last week, and now the numbers are almost exactly the same as with OGL on the same HW, which to me means that we're getting all we can from the hardware. ###@###.### 2005-04-09 00:23:28 GMT
07-04-2005