dc-js / dc.graph.js Goto Github PK

When there's a ton of data points in the vizgems viewer, the timeline eats 100% cpu in ticks.each.

Isn't there a better way to do hierarchical binds?

When the original of a parallel edge points leftward, text is reversed wrong

Who knows, you may not want overlap avoidance.

Although Edge recognizes the alignment-baseline style and the middle value, no value seems to have any effect - it's always aligned with the baseline. Probably there is some subtle difference here.

MDN suggests dominant-baseline - I didn't read the docs carefully but this also has no effect.

wouldn't want this always. maybe a special key press when already hovering (#12)

currently the new nodes & edges fade in in their final position.

if there are other graph elements migrating to that position (as there usually are), this has the disconcerting effect of having disconnected edges fade in, and afterward their end-nodes move to fill the gap.

two fixes:

• the simpler: have the edge start position be not the final position of the moved node, but the start position. at least nothing is disconnected this way.
• new nodes could also have start positions relative to their neighbors. this would require finding the whole component and all of its connections to existing nodes, and averaging them.

this requires passing back the actual set of nodes and edges displayed, somehow.

we don't have a concept of that currently - the knowledge of the current set is internal to the diagram. it would be a subgraph of the input node & edge crossfilters because of induced nodes and zero-degree node elimination.

unclear to me if this would mean separate crossfilter or if the magic of dimensions not observing their own filters is appropriate here. it would be good to have another application than just the legend - like display stats on the shown nodes & edges - to understand this better. (you would also want to display stats on a selection which is again an unrelated subgraph...)

To describe it politely, this is an abomination:

• time formatting is incomprehensible (I think those are actually hours)
• too many Y axis ticks
• y axis labels are too long for the area
• titles are too long and formatted too large
• some background area should be reserved

there's a complicate api design problem here, and i haven't found a good solution.

we're trying to generate constraints for cola.js based on the dynamic graph data that is available. right now we're passing the internal data structure, which means the client needs to go through s.orig.value.class kind of stuff that they don't care about.

i just don't know what's better. it is always going to be complicated, because it's an interface that takes processed data from the library and produces other data which needs to refer to existing objects. the whole names, indices, and references thing...

we calculate the final arrow orientation and apply it immediately in calc_new_edge_path

old and/or new orientations should be applied in sync with the staged transitions, and also animated.

the _running flag is not set.

and edge labels

I started to implement this in the node-line-breaks branch but the vertical alignment was wrong for any odd number of lines, so I stopped. I'm also not convinced it's going to get the height right. (I didn't see it expanding the nodes for up to three lines.)

With SVGs marker orient="auto", markers on svg paths use the first or final segment in the path.

This is pretty much the wrong idea for beziers, where the apparent direction of the line has little to do with the direction of the segment going from the endpoint to a control point.

As with #26 marker color, it looks like we'll have to dupe the markers for each edge, if we want to adjust individual parameters like the angle here.

opacity is zero.

currently only read from inventory node, which can result in too many unknowns. can also be read from ostype of edge, which of the form type2type. check if they match, at least use edge ostype if node does not specify.

will introduce at least one new type, hypervisor.

Equivalent to dc-js/dc.js#1006 - we're not using baseMixin so we need to implement the same detection of a d3 selection that fixed that over there.

I still think there is too much different about dc.graph.js to actually derive directly - e.g. we don't need the composite chart stuff that is much of baseMixin.anchor. But note that dc.leaflet.js does derive without many problems, even though it has even less in common.

It would be great to support other layout algorithms such as

• tree layout - here is one variable-sized layout we might use, based on d3's tree layout.
• d3's force layout
• dagre?
• dynagraph? graphviz? if we're willing to go server-side.

In terms of the model and parameters, cola is probably the most complicated, so this may be a matter of moving general stuff to base classes and creating a hierarchy of layouts. Constraints is something no other layout algo has, afaik.

Obviously the parameters that affect layout will all be applied differently, so there's some kind of generator. But the parameters that just affect drawing parameters may be shared somewhat.

Not sure why why have our own generate_path doing its own error checking and string generation.

It's odd that everything else in cola.js is wrapped with a dc.graph.js API, but not this one.

line can be seen poking out under arrow, esp if thick or another color

It would be great to build threading into the library itself.

This is possible because there is a clear separation between layout and display. Would just need to ferry the data between the sides, where now cola is directly changing the objects we use to draw stuff.

Right now the app gets unresponsive while layout is happening, and it's hard to tell if you've changed something or if something actually is broken like in #19.

Hi Gordon,

I've been meaning to give your dc.graph.js library a try for some time. I checked out your example in Firefox and get this issue on line 1295:

SyntaxError: in strict mode code, functions may be declared only at top level or immediately within another function

I'm completely new to Javascript, but the issue seems to be that you're declaring the the original() function in an if statement.

Works fine in Chrome though, it seems like it's more lax than Firefox.

Standard behavior of d3.dispatch and d3.selection.on is to return the current listener if it's not specified - just like any getter.

some initialization is stuck in there which is for all edges

some layouts turn out better if you insert the nodes in a particular order.

it would be nice to dig more deeply into the layout to make this unnecessary, but for a first pass let's just add a sort/ordering key (or keys, for edges too)

this means duplicating the marker, unfortunately - annoying but should be efficient enough.

Render a chart twice and _needsRedraw seems to get stuck, resulting in hundreds of cancelled messages on the console, and no chart.

some of the transitions don't complete so it thinks it's still running.

Weirdly, the text displays differently during transitions:

Versus when standing still:

on dragging a node. paths turn to NaN,NaN

currently there is a little bit of animation due to the layout iterations, but there's a big jump from the previous layout to the first iteration.

it might be better to

• limit the number/time of iterations
• skip the display of intermediate layouts
• animate from the last layout to the current one

it's squeezed in there perfectly with no extra space. a little buffer would be nice, .nodeMargin(accessor:{x,y})

we have wheel and we have clique. how to put a node in the middle of the circle?

maybe the hub isn't layed out by cola and is just a centroid, since we know how to do the circle.

the webworker refactor appears to have broken constraints

#charts-positioner simply covers over the checkboxes and half the type select

"radius" is actually half-height.

we should transition to node width & height like graphviz uses.

right now the radius actually determines half the height, and the "x radius" is determined using by fitting the label. it has evolved weirdly from circle through ellipse to polygon.

sometimes when clicking on a node, the titles appear but the charts are empty.

my guess is that the old charts may not be completely deleted.

two variants: drag and release, drag and pin. probably use modifier key to choose.

need i say more?

When the edge is pointing to the left, just above or below π, and crosses to the other side, the transition spins all the way around the other way.

(I am guessing that this is actually zero in our uncorrected SVG down-positive coordinates.)

Right now, if node A is to the left of node B, then the first edge from A to B (in the order of the array returned from edgeGroup.all()) gets drawn straight, then the next one above, the next below, and alternating above and below from there. It doesn't take into account which direction the edges are.

• Since the straight edge is strikingly different, whether to draw it at all should might be an option, or whether to draw one edge straight but two edges both curved, etc.

There is also the distinction between directed and undirected edges, and it seems that when there are directed edges,

• it might be desirable to draw all edges from A to B above, and all edges from B to A below, so that a cycle is clockwise and all edges in one direction are on one side.

For example, this looks wrong:

The directed edge from the top blue node to the orange node seems like it should be on the right (left from the source node's perspective), to emphasize that it's part of the chain, not running "head on" into the other edge.

There are many possible representations, and it might boil down to node ports instead.

it could be that they were never quite right. but i think they've gotten worse.

right now all the changes happen at once, which is sort of efficient on time but potentially confusing because stuff is fading out while other stuff is moving over it.

consider using staged transitions as described in Heer & Robertson where at least departing objects fade out before the rest of the changes start. possibly new objects should fade in after the other actions, too.

http://vis.berkeley.edu/papers/animated_transitions/2007-AnimatedTransitions-InfoVis.pdf

you specify the graph with key accessor and source/target key accessor, but when you build constraints you need to use the node index. that's troublesome

there is code to fade the opacity to zero, but they seem to pop out of existence.

i can't tell if this is due to competition for the processor. (i don't think so.)

occasionally it does work. could it be preempted by another transition?

fade in of new nodes and edges consistently works.

Pretty much the whole API is accessors, and "Accessor" is eight characters I'd prefer not to type all the time. Also most parameters can take constant values, so they aren't necessarily accessors.

While we're young and not too many people are using this, let's deprecate the *Accessor names, devise shorter names, and use the shorter names everywhere internally.

sometimes (when the stats are hidden?) the options show/hide and all the controls to the right of the ostype select do not react to the mouse.