Speaking at JavaPolis on 14 December, Luciad will share some of its eight years of advanced Java experience in the context of advanced graphical applications.  The presentation focuses on some of the techniques used to obtain the high performance of LuciadMap and discusses pros and cons, do's and don'ts.  For developers new to Java graphics, it should be clear that Java holds no limitations for high performance graphics, the more advanced Java graphics developer may pick up a few new ideas.

Foolish or brave
From the start in 1999, LuciadMap was implemented in Java. The Java platform has proven to be very well suited for high performance graphical applications, such as high demanding 3D and 2D visualization for air traffic management systems.  Moreover, the Java platform has allowed LuciadMap to take advantage of the recent hardware evolutions (such as the availability of multi-core CPUs) in a transparent way.

Java, OpenGL, and Swing
The high performance requirement for displaying static and moving geo-referenced recorded or realtime air traffic data in 3D has had a big impact on the design choices.  In the early design stages, OpenGL was preferred over Java3D because OpenGL allows direct rendering of the data, without building a 3D scene graph.  An internal abstraction layer allows to easily choose a specific OpenGL binding.  The supported OpenGL bindings have evolved over the years, from GL4Java over JOGL to the JSR-231 binding (actually also known as JOGL).  The JSR-231 binding has proven to be the most stable one, and currently provides the most rich API capability.

The use of NIO buffers is important.  NIO buffers allow the setup of a pipeline to quickly pass terrain data from disk to the OpenGL hardware, without involving Java memory allocation.

A number of language independent OpenGL techniques are employed, such as the use of vertexbuffers and other primitives for fast rendering.

Using OpenGL components in a SWING application also needs special attention, since OpenGL components are heavyweight components.  Issues with moving and resizing windows, with heavyweight menu bars and tabbed panes, can often be solved by applying “Context sharing”, an OpenGL functionality that is only available in the JSR-231.

Java for high performance soft-realtime applications

Java’s garbage collection has always been one of the key Java characteristics, being a blessing for the developer who does not have to worry too much about memory management and at the same time a source of worry for those who are concerned with responsiveness, efficient memory usage, and performance in general.  Soft-realtime applications need an almost 100% guarantee of reaching a given display rate and responsiveness of the application.  Operational ATC (Air Traffic Control) applications, for instance, require a guarantee that an update of the screen is done each 300ms.  Therefore it is a challenge building soft-realtime applications with Java.

Techniques such as object pooling try to give the developer more control over memory management, but they do not always provide the optimal solution.  To a large extent, the solution is provided by the Java platform itself by the garbage collection improvements and tuning possibilities in the JVM.

In the context of high performance graphical applications, special attention should be given to the concept of multi-threading.

Multi-threading

A well known principle for building responsive applications is to make proper use of multithreading.  Basically all time consuming processing or I/O needs to be done in another thread than the GUI updates, so that the GUI thread is minimally blocked and can respond to user interactions.  In the context of graphical applications this may not be sufficient: the graphical rendering that is part of the GUI updates may already consume a considerable amount of time, and hence have an impact on the responsiveness of the application.  A typical time consuming process in the context of 2D graphical applications is label decluttering.

LuciadMap’s “Paint in background” functionality uses the commonly known idea of drawing the GUI in an image on a separate thread, and then visualizing the image on the screen.  Although this sounds simple, it is not always the case, since it is possible that rendering settings are changed while the rendering on the offline image is still ongoing.  It means that applying the changes and the actual drawing must be properly sequenced.