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.
  xxxxx@xxxxx   2005-06-04 17:23:37 GMT

N/A

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%
  xxxxx@xxxxx   2005-06-04 17:23:37 GMT

This is essentially the follow-on fix that I alluded to in 6255545.
  xxxxx@xxxxx   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.
  xxxxx@xxxxx   2005-06-05 19:17:04 GMT