Wrong label when using id field

Issue type Despite using label: 'data(id)', nodes can have duplicate (wrong) labels while still having the correct id.

Bug report

Environment info

• Cytoscape.js version : 3.14.0
• Browser/Node.js & version : Chrome 80.0.3987.106

Current (buggy) behaviour

The bug causes duplicates of one label on different nodes while using the ID as the label.

Desired behaviour

Since Ids have to be unique (and it is, infact, unique), a duplicate label should be impossible when using the data(id) selector.

Minimum steps to reproduce

Here is a simple reproduction of the bug using the given template. There are no complex things involved, just some nodes and the style.

https://jsbin.com/cugeqamoxe/1/edit?html,css,js,output

[maxkfranz]

Related: Possible cache issue, how to diagnose? #2562

@josejulio

[maxkfranz]

@ng1905 See the hash-label-2636 branch and commit 0e01d53. That may address this particular case, but I’d like to see more data.

The explanation from the commit follows:

A hash function is used to create a single value that can represent the set of the style property values on an element. This is used for caching parts of the scene, e.g. labels and node bodies, as sprites. This way, things like labels don’t have to be rendered each frame: They can just be copied from a cache.

Using a hash allows for sharing cache entries between elements: For instance, an edge could have a number on it to represent multiplicity, and so multiple edges may have the same label. The typical case for the hash is node bodies: You may have a graph where all the node bodies are identical, with only one cache entry (sprite) shared among all nodes.

The hash is used to avoid lengthy style comparisons (i.e. 1 value comparison versus N style property value comparisons). The hash function has to be cheap and it should have a relatively low probability of collisions for a typical stylesheet. It may not be practical for performance to use a typical hash map approach where the entries are compared on a get operation (i.e. a diff of all style properties between two elements): The point is to avoid expensive style comparisons in the first place, and ideally you want lots of elements in the same buckets.

The problem here is that the prior hash algorithm collided for particular labels. The previous hash function didn’t do well for repeated values (like the repeated ‘0’ characters in the test case). This commit changes the hash function to an implementation that may fare better in this regard.

If this continues to be a problem in future, there are some alternatives:

(1) Don’t use hashing at all. You can lose a lot of performance, especially for shared node bodies. This also precludes the future enhancement of caching edge arrows (currently expensive and uncached).

(2) Don’t use hashing for labels. Most graphs only contain node labels, and node labels are almost always unique. There is the potential for node body collisions, though perhaps less likely.

(3) Use an alternative mechanism to generate a hash value. For example, a trie-like structure could be used: Each node in the trie would be a set of style property values, and each edge in the trie would be a particular property value. The leaves of the trie would each be assigned a unique integer. While this may work, it would be expensive and more complex.

(4) Double down on hashes and probability. It would be simple and cheap to use two cheap hash functions rather than one: The hash for a sprite would be a tuple of two integer hash values. The probability that both hash functions collide in the exact same case is much smaller than the probability that one hash function collides.