We should add an (alternate) OpenGL-based Java 2D pipeline for Windows.
Initially this will be enabled only by a flag (similar to the current situation
on Solaris and Linux).  This pipeline has the potential to offer better
performance (in some cases) than the existing GDI/DD/D3D pipelines, and may
also integrate better with other OGL-based libraries, such as Java3D and JOGL.

N/A

An initial prototype has been developed that demonstrates the viability of
this pipeline.  As we've found with the DirectDraw and Direct3D pipelines,
there are many driver inconsistencies that can produce unexpected results
with the OpenGL pipeline enabled (rendering artifacts, etc), so we'll have to
deal with those eventually.

There is one major difference in WGL compared to GLX: most drivers use the
WGL_render_texture extension as the only approach to getting pbuffer contents
to the screen (as opposed to the GLX/WGL_make_current_read approach).  So it
looks like we'll need a couple new blit loops that know how to get a RTT
surface copied to another surface.
  xxxxx@xxxxx   2004-03-04

The pipeline can be enabled with the -Dsun.java2d.opengl=true system property.
There are still many video cards out there for which we cannot enable the OGL
pipeline (required extensions not implemented by the drivers, etc).  There are
also many driver versions that can cause the OGL-based 2D pipeline to crash,
so it is strongly recommended that this flag not be used for deployment purposes
(e.g. in a JNLP descriptor).  Future releases will automatically be able to
determine whether the OGL pipeline can be enabled.  For Tiger, this flag should
be used for testing purposes only (so that developers can test their
applications with the OGL pipeline and submit feedback so that we can refine
the pipeline accordingly).
  xxxxx@xxxxx   2004-03-30

Tiger-beta2 crashes Windows or displays images incorrectly at the wrong place on ATI Radeon 9600, if the OpenGL pipeline is enabled for Java2D. Also affects Radeon 9700 and 9800, and other ATI boards.
Apparently this is a synchronization problem between the OpenGL pipeline thread and the hardware operations, or it may be caused by inconsistent switches between DirectX and OpenGL by competing applications (notably the Windows Explorer desktop which only uses GDI+ and DirectX).