LinMap - Possible Extensions and Improvements

Nic Geard (nic@itee.uq.edu.au)
18 October 2006

Optimisations:

Removing duplicate CxBlocks

It is currently possible that a CxColumn may contain adjacent CxBlocks mapping to the same lineage (due to the recursive algorithm).  The CxMap data structure could be optimised by removing these duplicates and merging adjacent blocks containing the same lineage (for one thing, this may speed up the binary search required to locate the currently selected lineage).

For the interactive version, this optimisation could be performed either automatically, after subdivision of a column, or manually, in response to a user request (depending on how long the operation takes...)  For a command line version, it would make sense to remove duplicates automatically.

Given that lineages are not currently stored, this would require either (a) generating each pair of neighbouring lineages for comparison; or (b) saving a hashcode for each lineage (possible calculated during generation of the lineage) for identification of equivalent lineages.

Improved threading

Currently, any operation involving modification to a map (subdivision, generation, etc.) locks up user interaction until calculation is complete.  It would be preferable if this calculation occurred in the background, while the user was still able to explore the current incarnation of the map.  The obvious (?) way of implementing this would be to have the calculation occur in a separate thread to the user interface.  

Note that these modifications (subdivision, at least) are done "in place" (i.e., the current incarnation of the map is modified): allowing simultaneous recalculation and interaction would require the original incarnation to be preserved until the new incarnation was calculated.

Fine tuning map painting

Every time paintComponent is called, the XY-locations, heights, widths, etc. of ALL CxBlocks are recalculated, even if that particular region of the screen does not require redrawing.  More could probably be done to optimise this process by restricting the amount of unnecessary recalculation.  At the very least the drawing parameters could be stored, and a flag used to ensure they were only recalculated if necessary.  

(but is this the bottleneck, or is it the drawing code?)

If it is the drawing code and repeated calls to painting rectangles, another possible solution may be to draw the map to an image file, rather than the screen, and simply dump this to screen when redrawing is needed.  See following for description of how to draw to an offscreen buffer:

file:///home/books/java%20docs/guide/2d/spec/j2d-image.html

Additional Functionality:

Saving and loading parameter sets

Currently it is possible to save and load entire maps.  It may also be useful to save and load parameter sets.  The resulting files would be considerably smaller.  One possible use case is to save a parameter set so a command line run can be used to generate a high-resolution map offline for subsequent visualisation.

Remapping X and Y axes

Ultimately it would be desirable to specify more flexibly the parameters/variables to which the X and Y axes are mapped.  For example, an axis could be mapped to either (a) and individual link strength; or (b) an individual node weighting -- that is the influence that a particular node has on all of its target nodes.

One further extension that this additional functionality suggests is a means of visualising networks as well as the lineages they generate, in order to facilitate exploration of different node / link combinations.

Customisable complexity gradients

Currently, all complexity gradients are linear, single-coloured and continuous.  For various purposes it may be useful to (a) change the colour of a complexity gradient; (b) include more than one colour point in a complexity gradient (eg. red->black->green, where black represents the landscape average); (c) introduce discontinuities (ie. so that 0.0 is black but 0.1 starts somewhere further up the colour spectrum; or (d) use non-linear gradients, for example a sigmoid gradient around a particular point would enable a greater colour spread around a particular point.

The Gradient class (from generation5) allows fairly easily defined multi-point gradients.  It could probably be extended to facilitate sigmoid scaled gradients and used as the basis for a dialog allowing user-customisable complexity gradients.

Modularisation / abstraction of code

There is currently a reasonable level of separation between the lineage model and the visualisation gui; however, this could be improved.  An obvious route would be to define the critical aspects of the gene network - cell lineage model in terms of interfaces, such that the gui code was more general.

Application to real networks

Currently the visualisation tool has been applied mainly to randomly generated networks.  There is no reason that it could not be used to explore the complexity space of real world networks derived from experimental data.  Such application would undoubtedly suggest further user functionality.
