[OpenJDK 2D-Dev] Making the OpenGL-Queue-Flusher work concurrently with AWT threads possible? (... the future of the opengl pipeline)

[Sergey Bylokhov]

On 15.01.2021 03:06, Laurent Bourgès wrote:
> Hi Clemens,
> 
> It reminds me our discussion few years ago, when I experimented opengl on linux and tuned the OGLRenderQueue for the Marlin renderer, see:
> - https://github.com/bourgesl/marlin-renderer/blob/jdk/src/main/java/sun/java2d/pipe/RenderQueue.java <https://github.com/bourgesl/marlin-renderer/blob/jdk/src/main/java/sun/java2d/pipe/RenderQueue.java>
> - https://github.com/bourgesl/marlin-renderer/blob/jdk/src/main/java/sun/java2d/opengl/OGLRenderQueue.java <https://github.com/bourgesl/marlin-renderer/blob/jdk/src/main/java/sun/java2d/opengl/OGLRenderQueue.java>
> 
> 1. These changes mainly consists in increasing internal queue buffer from 32K to 1 Mb (based on my own performance tests).
> Ideally an heuristic (data volume per second) could help estimating the appropriate queue capacity needed to automatically optimize the producer writing / consumer reading speed.

The problem with increasing the buffer is that it can cause unexpected spikes during drawing -> Most of the draw operations will work faster because all of them just put the "draw operation" to the buffer and the flush will occur less often, but the flush operation itself will be slower. Imagine a situation when the user draws something on the screen while the 1 Mb buffer is full.
Also note that executing OGL commands in native on the OGLRenderQueue does not mean that the picture is rendered on the screen, it could be possible that the picture will appeared at the end of the buffer when will call glFlush/glFinish, so the lag could occurred when we flush 1Mb vs 32k.


-- 
Best regards, Sergey.