[EmulGL] Can improve polygon rendering performance for dense mesh?

[jzy3d]

Verify if jGL line & polygon algorithm May be improved

• Inc_x use intermediate method call not usefull
• incrément using bit shift is faster?

triangle

• is it faster to avoid method calls and directly put pixels and increment when drawing horizontal pixel lines in a triangle ?

Inspiration

• http://www.csun.edu/~vj614913/Nov11/Implementation_of_a_3D_Graphics_Rendering_Pipeline_Using_a_Field_Programmable_Gate_Array.pdf#page48
• https://en.m.wikipedia.org/wiki/Bresenham%27s_line_algorithm
• https://en.m.wikipedia.org/wiki/Line_drawing_algorithm

Try colorbuffer with nio / direct buffer instead of array ?

[valb3r]

@jzy3d I've created small test https://github.com/valb3r/jzy3d-api/blob/5618f53b6f4d9dcd14ca33791e6d482b300de48f/jzy3d-tests-java9/src/test/java/org/jzy3d/performance_jmh/TriangleRendering.java

Currently it does not seem that avoiding method calls helps, as probably JIT simply inlines those methods:

Benchmark                                 Mode  Cnt    Score    Error  Units
TriangleRendering.barycentricRender       avgt    6  549.274 ± 18.146  ns/op
TriangleRendering.scanlineNewRender       avgt    6  217.430 ±  9.618  ns/op
TriangleRendering.scanlineOriginalRender  avgt    6  212.287 ±  8.291  ns/op

Difference between scanlineNewRender and scanlineOriginalRender is within confidence intervals

Probably tile caching and rendering cached tiles is the only thing that can outperform scanlineOriginalRender or Vector API based rendering

[jzy3d]

Great you explore this @valb3r and many thanks for making your results clear and readable.

I am not sure tile caching is worth for plotting : as discussed (a bit) in the EmulGL AWT readme, one way of using less CPU ressources is to only repaint on demand, in other word only if anything in the view changes (if viewpoint change or scene content change). In this case, anything in a cache will only be used once.

The only direction I found to improve visual performance is to reduce the amount of things to draw, e.g. removing the face of the polygon yet keeping colored wireframe.

Another similar idea, introduced recently, is to have several possible LOD (Level Of Detail) configuration and let the tradeoff between performance and level of detail be processed at runtime, depending on the number of pixel to draw. An exaggerated example is a shape with millions of polygons : when you want to rotate it, it is actually better to only draw the bounding box of this shape for fluid rendering than trying to draw the polygons mesh with lags.

I however might not have think about all possible low level optimizations, so it's great you explore this.