JDK-6280588 : OGL: avoid enable/disable GL_TEXTURE_2D around every texturing operation
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 5.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: generic
  • Submitted: 2005-06-04
  • Updated: 2008-02-06
  • 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-6255545 - OGL: avoid redundant texture state-setting calls
Description
The OGL pipeline currently plays it safe when it comes to enabling and disabling
GL_TEXTURE_2D state.  For every operation that uses texturing, we have code like
this:
    glEnable(GL_TEXTURE_2D);
    ...
    // draw texture mapped quad
    glDisable(GL_TEXTURE_2D);

Obviously this results in unnecessary (and expensive) state changes, especially
when there are many consecutive texture-based operations.  This is a common case
in Swing apps, where much of the time is spent rendering text and small icons,
both of which are texture-based operations.
###@###.### 2005-06-04 17:23:37 GMT
Comments
EVALUATION We should augment the CHECK_PREVIOUS_OP() macro (added in the STR timeframe of Mustang) so that we can enable and disable texturing only when necessary. Once texturing is enabled, it only needs to be disabled for certain state changes (like changing the context, and perhaps setting a complex clip, just to be safe) and when we're about to render a simple primitive in a glBegin()/glEnd() pair. Initial experiments show that with this change on Solaris/SPARC with XVR-1200, we could have the following improvements in performance (according to J2DBench): 1x1 drawImage() +110% 20x20 drawImage() +105% 100x100 drawImage() + 20% 8 ch drawString() + 56% 20x20 AA fillOval() + 10% 250x250 AA fillOval() + 8% 250x250 AA drawLine() + 14% And on JDS (the usual 2x 2.6GHz P4 w/ Nvidia GF FX 5600 and 7664 drivers): 1x1 drawImage() + 79% 20x20 drawImage() + 81% 100x100 drawImage() + 3% 8 ch drawString() + 40% 20x20 AA fillOval() + 5% 250x250 AA fillOval() + 3% 250x250 AA drawLine() + 8% ###@###.### 2005-06-04 17:23:37 GMT This is essentially the follow-on fix that I alluded to in 6255545. ###@###.### 2005-06-04 18:08:19 GMT Updated the above performance numbers with some modest wins for antialiased shapes. SwingMark scores improve only very slightly with this fix; Swing typically does no more than 2 to 10 similar operations in a row, and in most cases, does only 1 operation before copying the result to the screen, so we are unable to batch enough operations to show much benefit from this fix. Applications that render similar primitives consecutively will obviously benefit more from this fix. ###@###.### 2005-06-05 19:17:04 GMT
04-06-2005