Server architecture

The J661 Server implementation is completely independant from the graphic framework used to render its widgets.

Server rendering pipeline

The Server widgets rendering pipeline separates the following elements:

• The ARINC 661 meta-definition for the widgets
• The UI-independant implementation for these widgets. Each widget correspond to one Java class which hold the values of the ARINC 661 attributes for the widget. The association between an ARINC 661 widget and its associated UI-independant implementation is specified in an XML configuration file. Note that there can be only one implementation class for one widget definition
• The UI implementations for these widgets are responsible for the graphic rendering for the widgets in the selected rendering framework. The association between an ARINC 661 widget and its associated UI implementations is specified in an XML configuration file. Note that there can be several UI implementations classes for one widget (the chosen implementation may depend on the widget StyleSet)

Server runtime pipeline

An ARINC 661 Server as specified in the ARINC 661 standard is event-driven, which means that its job is to:

• Interpret pilot actions and send the associated events to the UA
• Decode UA messages and update the display

Decoding the messages and updating the display can't be performed in the same Thread, because:

• Usually receiving from a protocol is a blocking task, which must be performed in a specific Thread to avoid to freeze the display^[1]
  See for example the receive method in the DatagramSocket class in the JDK, which says that This method blocks until a datagram is received
• All the updates in the widgets renderers following the reception of a Buffer from the UA must be performed in the UI Framework Thread. Usually doing graphic updates in other Threads can result in unintended results or even exceptions

Considering that, the pipeline for the widgets rendering during runtime works as specified below:

• A specific Decoder Thread is created for each Channel to listen for buffer receptions on this Channel
• When a Buffer is received on the Channel, the Server decodes the content of the Buffer in this Thread and updates the associated widgets implementations propertie^[2]
  By default the Decoder filters only the ARINC attributes which have realy changed. For example, if the UA sends twice the same value for a widget PosX property, only the first update will be outputted by the Decoder.
• After the decoding, a task is spawned in the UI Framework Thread to update the associated renderers. Note that because a Layer can be rendered more than once in the cockpit, there will be an update for the widget renderers for each rendered layer

Updating the widgets renderers

For all the widgets which have been updated in the decoded Buffer^[2]

By default the Decoder filters only the ARINC attributes which have realy changed. For example, if the UA sends twice the same value for a widget PosX property, only the first update will be outputted by the Decoder.

, all the corresponding Layer renderers must be updated^[3]

For one Layer there can be more than one associated renderer in the cockpit, because a Layer can be rendered more than once

. This is achieved by the separation between the LayerPainter and the LayerRendererBridge:

• There is only one LayerPainter for each Layer
• There is one LayerRendererBridge for each Layer renderer in the cockpit

For each LayerRendererBridge, each widget will be updated only for the kind of properties which have really been updated:

• StyleSet: this is necessary because a Server renderers configuration file#Widget Multiple renderers declarations. This is performed directly through the LayerRendererBridge without calling the widget renderer
• Layout: Layouts updates are usually more complex and need more time to be performed than other changes, so it makes sense to separate these in the widget renderer implementation
• Position
• Other properties: these are the most simple of updates

Note that the update of Map widgets is a bit more complex. See J661 Maps management.