The OGL-based pipeline added in 5.0 is not as reliable as it could be. A
typical (native) OpenGL app has one and only one rendering thread, so all
OGL commands are issued on that single thread. The OGL-based Java 2D pipeline
doesn't have it so easy because rendering requests can come from any number of
threads (the EDT, a user thread, etc) even though we try to teach developers
to avoid doing heavy rendering to hardware surfaces from many threads. It is
possible to write an OpenGL app that renders from multiple threads, but you
have to take many precautions to make that app reasonably robust, such as:
  - ensure only one thread is calling OGL methods at any given time
  - use FBConfigs and contexts only from the thread on which they were created

We went through great lengths in 5.0 to adhere to these restrictions, but in
the end we can only be as robust as the OGL drivers underneath us, and in
many cases those drivers are not very reliable when many rendering threads
are in use at the same time. There is also a performance issue here because
for any given rendering operation, we need to first fetch the appropriate
context from thread-local storage (this is usually pretty fast, but it would
be nice if we could avoid it altogether).

We could make the OGL pipeline much more reliable if we played nice like
those typical native apps that only render from one thread. One solution
would involve enqueuing rendering operations (or any operation that talks
to OpenGL) on a buffer, and then having a single separate thread that is only
responsible for flushing that buffer periodically. This would allow any
number of Java-level threads to issue rendering requests, but in the end only
the single queue flushing thread would be calling OpenGL methods.
###@###.### 2005-1-20 00:16:06 GMT