From this minimal reproducible sample you could see that packComponents takes too much time to calculate. (180 seconds)

The graph in the example contains 4 connected components, 157 nodes, and 154 edges. I think it should handle it faster

Let's get rid of unnecessary dependency to view-utilities. The demo could use view-utilities if needed but not the extension itself as these are two independent extensions.

Currently, the utility's place hidden neighbors method assumes only 1 level of hidden neighbors to be shown at one time. However, in some cases (e.g. Newt), one might need to show multiple levels. We need more of a holistic approach for handling this rather than showing one level at a time.

Currently the options for configuring packing is in README but nothing related to the usage of these methods.

• 1. "Desired Aspect Ratio" => "Desired aspect ratio" and so on everywhere including dropdown box content (only capitalize the first word)
• 2. Move Result aspect ratio and Result fullness in "Pack components" section
• 3. Make the step increment/decrement 0.1 for Polyomino grid size factor as well
• 4. Display results only 2 digits after decimal point
• 5. Doesn't look like Result aspect ratio is calculated (taken from?) correctly as it's almost always the same as Desired aspect ratio
• 6. Relabel nodes consistently n1, n2, ...
• 7. Also display "Result adjusted fullness".

Hello,
I'm currently working on creating compound graphs relying on fcose, and trying to take advantage of layout utilities for packing the nodes. Reading the documentation and playing with the options, I currently didn't succeeded in removing some wasted space with packing utilities. I attached a snapshop of the graph I obtained plus the layout options I used.
I've to admit I'm a little bit lost with all the parameters and what should results from their combination.
Any suggestion on how I should parameter the layout in order to reduce the wasted space?
Thanks in advance for your support.

/// Definition of the layout for the compound graph interactive viewer
var layout1={
name: "fcose",
randomize: true,
// fisheye: true,
animate: 'end',
fit: true,
nodeDimensionsIncludeLabels: "true",
condense:true,
gravity: 1000,
gravityRangeCompound: 100,
gravityCompound: 100,
gravityRange: 3.8,
packComponents: true,
// initialEnergyOnIncremental: 0.3,
// nodeRepulsion: node => 10000,
// idealEdgeLength: edge => 10,
// edgeElasticity: edge => 0.45,
// nestingFactor: 0.1,
numIter: 50000,
quality: "default"

};
/// complementary layout with parameters to define when randomize is not used for layouting
//packing
var layout2= {
idealEdgeLength: 1,
offset: 20,
desiredAspectRatio: 10,
polyominoGridSizeFactor:0.1,
utilityFunction: 1,
componentSpacing: 1}

When the utility of packing of components is used for disconnected graphs, the components may end up in locations which are completely different than their original ones.
Instead, we should compute the center of a minimal bounding box based on input positions and adjust the output to be centered at this location as well.

Currently edges are assumed to be straight lines by this extension. We should either:

• ask the users to pass a minimally sized dummy node for each bend point in README, or
• allow users to include bend points as part of each edge

If you hide edges in the demo and try to make them reapper by clicking "show all" it doesn't restore them. However, it restores them if you use the "show hidden neighbours" option.

When we have few components incremental packing is not stable as seen below. I suspect that an edge might be created between the red component and the small blue component down to the right in this case, yielding such a result:

While debugging #26, I came across another bug with below graph with two components. The larger component contains 6 non-multiple edges. But when we call packing here, an inspection of the start and end coordinates of the 6 edges reveal that (n5,n7) is listed twice and (n6,n8) is missing!

      nodes: [
        { data: { id: 'n1', name: 'n1' }, position: {x: 0, y: 0} },
        { data: { id: 'n2', name: 'n2' }, position: {x: 0, y: 100} },
        { data: { id: 'n3', name: 'n3' }, position: {x: 100, y: 100} },

        { data: { id: 'n5', name: 'n5' }, position: {x: 200, y: 0} },
        { data: { id: 'n6', name: 'n6' }, position: {x: 200, y: 700} },
        { data: { id: 'n7', name: 'n7' }, position: {x: 700, y: 700} },
        { data: { id: 'n8', name: 'n8' }, position: {x: 700, y: 0} },
      ],
      edges: [
        { data: { source: "n1", target: "n2" } },
        { data: { source: 'n2', target: 'n3' } },
        { data: { source: 'n3', target: 'n1' } },

        { data: { source: "n5", target: "n6" } },
        { data: { source: 'n6', target: 'n7' } },
        { data: { source: 'n7', target: 'n5' } },
        { data: { source: "n5", target: "n8" } },
        { data: { source: "n6", target: "n8" } },
        { data: { source: "n7", target: "n8" } },
      ]

Let's change 'componentSpacing' default from 0 to 30. Using no spacing between components makes it very difficult to distinguish components.

• Let's remove redo layout as it's redundant (see the Rearrange on Hide/Show checkbox)
• Coloring nodes with hidden neighbors works only one time on hide but we lose this with the next operation (same behavior with the demo of this extension). Let's discuss.

When we have new nodes in a graph and want to place them in available, empty spaces near their neighbors, we use placeNewNodes with new node list as a parameter. However, this does not seem to be working properly and placing new nodes in spaces that are already occupied even when there is available space around its single neighbor.

• Take a graph with a good layout
• Mess up the layout
• Select a single node and apply "Show hidden neighbors of selected"
• Notice how only some nodes move and others (messed up part) stays messed up. I am guessing this is a demo bug, hopefully not a bug with the extension's hide/show facility.

Let's make sure unstable has all changes in the master branch.

Sometimes the components are too close to each other, which might not be desirable by the user. There should be an option "componentSpacing" that is zero by default by could be a positive number, increasing the space between components. This could be an option used to extend the bounding rectangle of each component so that they are taken to be bigger than they actually are.

I was trying to pack two disconnected nodes and realized that sometimes code runs into infinite loop. I think it's this loop in which the cells variable becomes 0 and cannot find placement. A sample case can be found here.

Currently reads https://.github.io/cytoscape.js-layout-utilities which does not resolve

We should illustrate how new nodes (neighbors of existing ones) can be initially nicely placed before an incremental layout can take place (placeNewNodes) in the Demo as well (maybe something similar to how we do it in CiSE demo when right clicked on a node).
In addition, README should be improved and all features should be properly documented.

It can be seen in the demo that setting polyomino grid size factor to a value less than 1 throws error in the console.

When integrating new nodes into an existing graph with a layout, the user could use the placeNewNodes API. When doing so we check whether or not the new nodes have neighbors with existing layout information but we ignore the parent-child relations. For instance, if a compound node is a neighbor of an existing node, this compound's children are also indirectly neighbors with the existing node. We currently completely ignore such relations.

When a graph is laid out and its components are packed, we get a nice compact layout of disconnected graphs. However, if some minor changes are made to the graph topology (e.g. adding some neighbors to one of the nodes), then the packing is not done incrementally when layout is done incrementally. If the layout is done non-incrementally, the user loses their mental map o the graph. So, let's see if we can find a way to make the current polyomino packing algorithm work incrementally.

Looks like we should try more neighboring levels for a good location to place the next polyomino before we make a decision. Otherwise, this is more or less the first closest place that works. Maybe at least maximum of half of width and height (# of squares) of the bounding box of the polyomino.

Non-incremental component packing fails in some cases like below. Unfortunately, I couldn't identify exactly in which cases it fails, but can generally be reproduced with a node setup similar to the example below. This bug is valid for both master and unstable branches.

How should I use this utility for compound nodes ?
When use layout cose-bilkent with tile true, the disconnected nodes which maybe have parent node or not, will be tiled together, but sometimes the disconnected nodes maybe layout far away from the connected nodes. Is this utility effective for such case ?

Notice that in case you make use of compound nodes, it's sufficient to pass only highest level (root) nodes in the nesting hierarchy.

I read this sentence from the description of this tool. Does it mean cy.elements(":visible[^parent]").components() ?

• 1. "Shift + taphold" seems to be not working, and also it's a bit confusing term, what does it exactly mean?
• 2. In the "pack components" section of the website, it might be a good idea to rearrange the order of the entries. And maybe creating a button to "pack components" rather than to use the title as a button would be more user-friendly.
• 3. In the "pack components" section, it would also be good to either hide or specify "Result" fields as empty before "pack components" was applied.

Our application sometimes hangs, and I've now spent several hours tracking down where the problem is.

Finally I found out, that the problem is with packComponents() method.

If I have to nodes, sometimes the following subgraphs are generated and this results in busy loop:

[
    {
        "nodes": [
            {
                "x": 0,
                "y": 0,
                "width": 45,
                "height": 45
            }
        ],
        "edges": []
    },
    {
        "nodes": [
            {
                "x": 55,
                "y": 0,
                "width": 45,
                "height": 45
            }
        ],
        "edges": []
    }
]

Below you can see the whole code:

    let cy = cytoscape({
      container: this.$refs.cyto,
      elements: this.generateElements(), 
      style: this.generateStyle(),
      autounselectify: true,
      userPanningEnabled: false,
      userZoomingEnabled: false,
      boxSelectionEnabled: false,
      autoungrabify: true
    });

    cyInstance = cy;

    cy.layout({
      name: "cose-bilkent",
      animate: false,
      idealEdgeLength: 20,
      quality: "proof",
      randomize: false,
      nodeDimensionsIncludeLabels: true,
      nodeRepulsion: 8000,
      edgeElasticity: 0.7,
      nestingFactor: 0.1,
      numIter: 10000,
      gravity: 0.25
    }).run();

    var packingApi = cy.layoutUtilities({
      desiredAspectRatio: 1,
      polyominoGridSizeFactor: 1,
      utilityFunction: 1,
      componentSpacing: 0
    });

    var components = cy.elements(":visible").components();
    var subgraphs = [];
    components.forEach(function(component) {
      var subgraph = {};
      subgraph.nodes = [];
      subgraph.edges = [];

      component.edges().forEach(function(edge) {
        var boundingBox = edge.boundingBox();
        subgraph.edges.push({
          startX: boundingBox.x1,
          startY: boundingBox.y1,
          endX: boundingBox.x2,
          endY: boundingBox.y2
        });
      });
      component.nodes().forEach(function(node) {
        var boundingBox = node.boundingBox();
        subgraph.nodes.push({
          x: boundingBox.x1,
          y: boundingBox.y1,
          width: boundingBox.w,
          height: boundingBox.h
        });
      });

      subgraphs.push(subgraph);
    });

    var result = packingApi.packComponents(subgraphs);

Let me know if you think the problem could be caused with our generateElements() or generateStyles() methods, I can then try and tidy them up. However they are quite simple methods and I think are not part of the problem.

With the component spacing of 30, incremental and non-incremental layout results in different actual spacing:

Non-incremental:

Incremental:

Let's make them consistent (by trimming values prior to the operations if needed). I think the default should be 80 and the non-incremental version should deduct a constant amount from this value to stay consistent.