RichLineTypes

<<TableOfContents: execution failed [Argument "maxdepth" must be an integer value, not "[2]"] (see also the log)>>

About this document

This is an official Request for Comment (RFC) for allowing easy addition of various new LineTypes. Note that this RFC is only about a small backend cleanup / fix, not about using the possibilities opened by that fix to add new LineTypes. (Although the latter is an argument for accepting the fix.)

For details on RFCs in general, check out the Wikipedia Entry: Request for Comments (RFCs)

Status

Open for public comment

How to Comment

To view/add comments, click on any of 'Comment' links below. By adding your ideas to the Wiki directly, we can more easily organize everyone's ideas, and keep clear records. Be sure to include today's date and your name for each comment. Here is an example to get things started: /Comment.

Try to keep your comments as concrete and constructive as possible. For example, if you find a part of the RFC makes no sense, please say so, but don't stop there. Take the extra step and propose alternatives.

Proposal

Currently there are only a handful of linetypes, (simple and dashed) and the current implementation only allows discrete mappings for linetypes. Small fixes in the cytoscape framework would make much richer linetypes possible. Examples of such are:

• multi-stroked lines (i.e. lines that are made of parallel lines)
• lines made of some repeated icon (stars, round dots, etc.)

In addition, the fixes that would make such extension possible also make the existing code cleaner, and (most likely) faster

General Notes

Currently LineType class has a private Stroke field. This gets initialized when creating the currently available types. However, the Stroke instance stored there is not used when rendering the network. Instead, it is casted to BasicStroke and it's width and dash parameters are extracted, and the instance is thrown away. The parameters are used to create BasicStroke instances during rendering. This makes absolutely no sense. The proposed fix would instead use the Stroke instance carried inside the LineType to do the actual drawing. This would make defining new linetypes much easier: one would simply need to create a LineType subclass that contains whatever Stroke one wants. For example of what one can do with custom Stroke instances see http://www.java2s.com/Code/Java/2D-Graphics-GUI/CustomStrokes.htm

To render the edge at low detail (which is needed for the "degrade rendering detail when too many things to draw" feature) LineTypes would have a new thickness field. For high-detail rendering the Stroke instance would be used, for low detail rendering, a BasicStroke with that given thickness. It is assumed that whoever creates a custom LineType would set this thickness value to the apparent thickness created by his custom Stroke instance.

This would make the code simpler (by getting rid of the "use BasicStroke instances to store thickness and dash parameters" unintuitiveness), and probably speed up rendering (as there would be no need to create BasicStroke instances on-the-fly as it is done currently).

Open Issues

The patch mentioned below removes some logic that changes the various CAPs and JOINs on the edges. This is done because I (DanielAbel) didn't understand that part of the code. If that part of the code is needed, and somebody can tell me what it is good for and how it works, I'll try to fix that, too.

Backward Compatibility

Changes are expected to be fully backward compatible.

Expected growth and plan for growth

• new linetypes could be defined much easier, even in plugins.

References

• Thread on cytoscape-discuss at http://groups.google.com/group/cytoscape-discuss/browse_thread/thread/e89be89bf30b4d5f

Implementation Plan

I (DanielAbel) have an experimental patch at http://abeld.web.elte.hu/use_stroke_patch.zip

The double-line type also included in that patch is an experimental version, included only to test the backend code and show an example. I will change / rewrite that if the patch is accepted. The cleanup / possible speedup aspect is independent of accepting new linetypes.

The current changes to cytoscape.visual I have been warned about were not taken into account when preparing the patch. (The patch is against svn trunk as of r9703 and such might not apply cleanly against current svn trunk. see the above-mentioned cytoscape-discuss thread for more details.) In addition small changes might be needed to ensure backwards compatibility and proper deprecation of removed methods.

• merge above-mentioned patch (or something like it)
• (optional) add new linetypes

Comments

(MikeSmoot) I believe that the caps and joins are related to drawing things when alpha blending is turned on. The idea is to make sure that lines don't overlap since this is visible with alpha blending. There is some test code in the csplugins SVN project under ucsd/nlandys/render.test that may be of help in determining if this patch maintains backwards compatibility correctly.

(DanielAbel) The 2.5 plans page (Cytoscape_2.5) mentions "Custom Node / Edge Graphics (MIMS)" as a postponed task. I dont know anything about the plans for that, but the "custom edge graphics" part seems to depend on features introduced in this RFC (or something pretty close to it).

(MikeSmoot) For the 2.6 release we're going to look at the underlying infrastructure needed to support MIMs and SBGN. There has also been another request for custom edges, so we'll look at refactoring the various bits of rendering code to support a Stroke interface.