Time

With a graph with thousands of graph elements (vertices and edges) it is important that a filter exists directly upon the data that is the output of the model. The Layout functions like an intermediate between the model and the view and should therefore be extended with a filter.

Deprecation

The AbstractLayout?.applyFilter() does indeed provide this functionality. However the Layout.getVisibleVertices() function is deprecated. A reference to the PluggableRenderer.setVertexIncludePredicate() is given, however this means that the whole big set of vertices will be handled by the viewer and the renderer while this isn't necessary.

Vertices iteration

Places where the whole set of vertices is iterated (and if coded correctly subsequently the acceptVertex method of the predicate is evaluated) are multiple:

• AbstractLayout?.applyFilter, that is correct
• AbstractLayout?.initializeLocations, only visible vertices should be initialized
• VisualizationViewer?.renderGraph, the locationMap will contain all vertices, renderer.paintVertex will be called for each vertex and only then will the vertexIncludePredicate start to function
• RadiusGraphElementAccessor?.getVertex(x,y,maxDistance), and apparently the layout has to know where to locate vertices that shouldn't be visible in the first place with layout.getLocation(v)
• ShapePickSupport?.getVertex(x,y)
• FRLayout?.update
• SpringLayout?.update and other methods
• EditingGraphMousePlugin?
• EditingPopupGraphMousePlugin?
• PickingGraphMousePlugin?

Solution

These all should iterate the visible vertices by calling layout.getVisibleVertices(). This would accelarate the process significantly with large graphs. So, Layout.getVisibleVertices should definitely not be deprecated.

Page last modified on February 26, 2006, at 03:15 PM

Edit Page - Printable View - Page History - Recent Changes - SearchWiki