How large data does cytoscape.js support to render?

  I have 10729 nodes and 4185 edges,when I render it,the view is blank. I can see the code it generate and drag the view,but I can't see the nodes and edges. 
  Then I decrease the number of nodes to 3000,it runs well.
  So I want to know how large data does cytoscape.js support to render.Looking forward to seeing your answers,Thanks 

[maxkfranz]

That’s a matter of layout rather than rendering performance. Layout quality and performance are a function of your data, your choice of layout, and how well you tailor the layout options to your specific dataset. Each layout has a demo that you can easily use to experiment with your data.

Here’s an excerpt of an email I wrote to someone else on the same topic:

–

There are several different types of layouts, and in our experience you really have to experiment with different layouts and different layout options to see which combination works best for your particular data. One important consideration, as you mentioned, is the overall number of elements. The main recommendation I can give you for large graphs is to use fCoSE if you want to use a force-directed layout (n-body physics simulation). fCoSE is a new layout that is faster than traditional force-directed layouts. A layout is just a function of node to position, and layout is one of many considerations in designing for a good user experience with large graphs.

The root issue with large graphs is that it is difficult for a person to visually parse so many data points at once. Even assuming that you never have performance issues with large graphs and that you make an ideal choice of layout, large graphs usually just become visual noise. Choice of layout can help with that issue to some degree. Large, highly-connected graphs tend to be more or less a hairball regardless of choice of layout. The problem, then, is to filter the elements to show only a relevant subset of the graph that a user could easily parse – and to allow the user easy navigation from one chosen subset to another one.

We are actively exploring solutions to this problem. For example, we have a tool called HiView that uses this subset approach with an ontology level selection metric. Another useful metric is topology combined with score: You can select a subset based on the graph topology relative to a chosen locus (e.g. N hops away from a chosen node), using some score or ordinal ranking to cut down that topological set to a reasonable size. When you have a ranking within a subset, you can also use a pagination-like approach to flip through to lower-scoring elements in the topological subset (e.g. using a slider or stepper). A simple example of a topological approach is the Wine and Cheese Map: The red and white wine edges are normally hard to see, like a hairball. By using filtering and layout based on the clicked node, the red and white edges of interest are more easily seen.

We also have a general list of performance-related tips that may be applied to your app.

[geotheory]

Many thanks Max, this is a great steer. I’ll certainly contribute anything I manage to get working that may be useful to others.