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.
