In recent fixes involving fragment shaders (6514990, 6521533) it became clear that
the OpenGL pixel pipeline can be quite long, meaning for complex operations happening
on the GPU it can take a while for the pixels to go through the complete pipeline
and appear on the screen.  Our current approach in the OpenGL-based pipeline is to
simply call glFlush() at the end of processing a batch of operations.  The glFlush()
method is basically a way to asynchronously flush operations pending in hardware.
This is one of the main benefits of hardware acceleration in that we can offload
complex work to the GPU without having to wait for it on the CPU.

Currently if you call Toolkit.sync(), all it does is force Java 2D's RenderQueue
to be flushed, followed by a call to glFlush().  This is usually sufficient for
ensuring that pending operations are flushed to the screen in a timely manner, but
for complex operations like the ones described above, it's usually not enough.
The problem] is that in certain scenarios (e.g. microbenchmarks, regression
tests that sample screen pixels via Robot) our current approach with glFlush()
does not always get the pixels to the screen in a timely manner.  This can wreak
havoc with J2DBench results (due to high variance) and can cause regression tests
to fail (because the hardware isn't flushed by the time Robot needs to sample pixels).