Blocks with no children coloring delay about dagviz HOT 7 CLOSED

The color is depicted from the state of the incoming data... The proper way of handling this would be to have Kasparov supply initial block data in a desirable state.

If not feasible, we can set up a timer-based animation, where a block will start in the "initial" color (TBD) and then turn to red if for T period it hasn't been a part of any reorgs or SPC selection (as otherwise it already turned blue).

from dagviz.

Color only depends the presence of acceptingBlockHash, correct?
While blocks would be normally colored blue or red, you can wait 15 seconds with the coloring of blocks with no children. Within 15 seconds, tips with no children that would normally be colored red, might get children in the SPC that would change their acceptingBlockHash.
After 15 seconds, the color would show and they would either be colored blue if the above happened, or red if it didn't.

You can change the coloring rule to this:

• For blocks with no children, show color (based on acceptingBlockHash) only after 15 seconds.

from dagviz.

Ok, understood. This will be done shortly.

However, for the record, I want to mention that I consider this to be somewhat of an incorrect approach. DAGViz should not make any assumptions about protocol or network behavior. If you, for example, change timing down the road, this might break things.

IMO the correct approach should be to get all of this information from MQTT, even if this requires additional MQTT messages.

It's the same reasoning as to why we wouldn't want to have linear access to the chain database... except in this case I think that linear access is ok, but the above is not very proper.

from dagviz.

Why do you think it's that bad?
It's merely delaying the presentation of color around the tip of the DAG, not changing it.

from dagviz.

15 seconds gives some time for the DAG around the tips to "settle". If there are reorgs around the tip during those 15 seconds, then you will less likely be seeing blues turn to reds and vice versa.

from dagviz.

The rule I wrote above:

for blocks with no children, show color (based on acceptingBlockHash) only after 15 seconds

should probably change to:

For blocks close to the tip (blocks with blue score close to the max blue score of the DAG): show color only after 15 seconds.
This is to enable the delay not just for the tips, but also to prevent color delay for any block that just gets drawn (when panning the DAG).

from dagviz.

superseded by #39

from dagviz.