Purpose

The following are brainstorming ideas that could be implemented into Constellation to make it even better. When it comes to Constellation the sky really is the limit!

Some issues that are more enhancement suggestions and future ideas, may come off the project issue backlog and onto this page if there isn't a willingness to investigate them for the foreseeable future.

The main reason issues have not been created for these ideas is to keep the backlog focused and more manageable. Note that issues below are not in any priority order.

General Ideas

Get feedback from surveys

New starter pack

Support different languages in Constellation

Refactor JSON Serialization/De-Serialization

Reimplement Banners - Open GL experience needed

Configure an Update Site

Implement Material Design

Investigate JUnit5 over TestNG

Hover elements gives summary of attributes

DGraph Connector

Add Preset Values for Max Expansions in Experimental Uncollide Plugin

Graph improvements

Convert undo and redo to plugins

Attribute Types Composed of Collections of Primitives

Simpler Attribute Descriptions - integrate prototype

Multi-Modal Graphs

Add context managers to the graph API

Formally define schemas and inheritance

Colourize nodes based on a given attribute value

Add ability for 'solid' images as a graph option

Add support for dynamic icons

Re-Work Composite nodes to handle larger compositions

Optimise renderer taking advantage of depth of field

Basic RDF Support

Consolidate Caches

View Suggestions

One-to-many element relationships in the Histogram View

Analytic View to support clustering and content analytics

Option to save defaults / load defaults for dialogs requiring input

Multi valued (set) attributes

Support edge and link attributes in views

Graph Animations

Migrate renderer to LWJGL

Ability to animate elements via a spatial arrangement based on a supplied formula

A Type should be able to specify 'alias' rules

Increase the flexibility of the Animation Framework

Animations hold a graph write lock for their duration and can only make changes to the graph itself on each frame. It would be nice to extend the framework to allow the following:

• Animations that only hold read locks (might sound strange, see the next point)
• Animations that can make anon-graph visual changes. In particular, direction indicators could be re-implemented in this manner, which would be nice as they could then be moved out of the base level GL renderer. Direction indicator animation ticket
• Animations that con be interacted with. This is tricky and would either require that they keep giving up their lock, or that there is some capacity to share a lock with the event handler.

Faster Animations

Presently animations are slightly slower, particularly on large graphs. This is because animations now hold a graph lock and use the visual manager to update the renderer (making them agnostic to the particular method visualisation), whereas previously the would write to open GL buffers directly.

Nevertheless, this shouldn't be that much slower. In principle it should be possible to analyse the flow of an animation and optimise it for faster performance.

JOGL Alpha Blending of Icons

When a foreground icon is displayed on a background icon, even if both colours are light, the alpha blending function that is applied appears to make the boundary region darker than both colours. This seems not to be an issue with the blending itself, but rather the JOGL utility method for placing icons on textures that appears to be doing something like pre-multiplying colour channels by the alpha channel. It may be the case that to solve this issue we should manually load icons into a texture with just vanilla GL statements.

Rewrite Shaders to conform with Label Shader

The re-write of the Label Shader involved a more streamlined approach to the dataflow through the OpenGL pipeline, a greater deal of care taken in determining which parts of the shader work was being done, and a commitment to verbose commenting. The label shader is demonstrably faster at rendering the same content than previous versions, other shaders should be rewritten with the same considerations in mind.

Anti-Aliasing the Graph Texture

Anti-aliasing has been disabled in the OpenGL renderer since the visual framework rewrite. This is because it was being performed in an old, non-recommended manner, was hampering performance and was causing artifacts and problems on machines where AA was not explicitly enabled on the graphics card.

Providing support for proper anti-aliasing would be desirable. The correct place to do this would be on the intermediate texture that the graph is draw to, which is then later drawn to the screen. When we draw tho this texture, we should enable multi-sampling. This needs further investigation into both its visual and performance ramification.

Plugin Reporter should act as an undo stack

The plugin reporter could act as an undo stack that allows the user to roll back to any point in the history of a graph (up to some memory -limit size obviously)

Rethink hit testing encapsulation and design

Hit testing is the one component whose OO design needs a bit of work. Whilst hit testing is only utilised in the "Interactive GL" module by the HitTester class, the "Core Interactive Graph" module has methods which explicitly share a GL buffer location with this HitTester class.

Furthermore, the vanilla renderer contains the option to (and code for) drawing the hit tests buffer, even though it is not used by anything at that level. It is a non-trivial issue to rethink how this could work in a nicer way so that the base GL renderer was blissfully unaware of hit testing.

Update graph views after the visualisation updates

Graph views all update synchronously as part of the graph listening framework. The visualisation updates by a different mechanism so that it can respond more quickly to rapid visual changes.

Occasionally, this means that the visualisation is significantly slower than the views to update. For example, adding a node to a large graph happens on the graph and views first, and then spawns visual changes which take a long while to be reflected as the entire graph has to be redrawn when nodes are added/removed. This means that for a short (usually a few seconds) the visual in the attribute editor/histogram/status bar are out of sync with the visualisation.

In these cases it might be nice to be able to require the graph listening framework to actually wait on the primary visualisation in use to complete its visual update cycle before passing on its changes to the other views.

Don't render graph elements hidden behind other graph elements

Currently the renderer will send all the nodes and transactions to be drawn, even if nodes and transactions are not visible because its behind another. This causes unnecessary load on the graphics card which causes it to crash on low end cards.

Using a simple example to explain what is required, consider 2 transactions crossing, what is required is to draw the transaction that is on top and also draw the transaction behind but not draw the overlap part. Same goes for nodes that are sitting entirely or partially behind another.

The best way to test this is create 1 million nodes and add them to the graph (preventing any arrangement) so all nodes sit on the 0,0,0 coordinate. A basic graphics card should be able to handle this because only 1 node would be drawn.

Allow applying label colour changes to only some nodes and transactions

Currently, label colours are a graph attribute and so when you change that attribute, it gets applied to all nodes (or all transactions depending on which is edited). What would be nice is to be able to only change the label colour of some nodes or transactions as this would allow greater flexibility in visualistion.