Hi Sergey, It is quite interesting! But it would be good to check what code was > affected by this parallelization. I meant we cannot draw much-much faster > than OGL draw its primitives, so even w/o parallelization if we will call > flush after each fillRect/etc(mimics the in-place rendering on the current > thread), we can speed up something but at the end, we will call OGL on one > thread. > So executing some code in parallel to the actual OGL rendering we speed up > the whole benchmark so much! looks like something(code executed in > parallel) works ineffective. >
Basically, all the pipeline-code on the java-side can now be executed in parallel with the actual GL calls: - rasterization of antialiased geometry - span/scanline generation of non-antialiased geometry - queue protocol generation - pipe validation - actual RenderQueue protocol generation - all the locking for each & every primitive So sure, for GPU limited cases this won't help a lot - however, typical java2d is usually CPU limited with tons of very small primitives and many state changes in between. Laurent has done a few benchmarks with mapbench where a ~30% improvement was achieved. Not mindblowing, but also not that bad: https://github.com/bourgesl/jdk/wiki/OpenGL-fix-benchmarks Best regards, Clemens
