-
Notifications
You must be signed in to change notification settings - Fork 59
Brainstorming Ideas
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.
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.
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.
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.
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 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.
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)
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.
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.
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.
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.