Prototype of SVG gradient for tree branches #897
Conversation
The layout code defined both the stem & tee of a branch in a single SVG path, however the rendering code treated these differently and expected 2 paths. We were therefore rendering both paths via the code only intended for the stem. This changes the display to draw stems over Ts. This should be improved by SVG gradients in future work.
jameshadfield
temporarily deployed
to
auspice-svg-gradient-osdh09srk
|
Fantastic work @jameshadfield! I'm super happy with this direction. I find the more continuous behavior to be more aesthetically pleasing, but I'd also note that people read a lot into these colors and (perhaps rightfully so) interpret an extended line of a particular color as arriving in that region at that moment, like so. Another good example of this would be the arrival of mumps into BC. The solid red line here makes it look like the arrival was 2013, when that's definitely not the case.
I experimented with this with basically all the live builds and I think it's a consistent improvement. My only concerns at this point are:
|
|
Great -- I'll find time to restore the functionality so we can use this 👍 |
|
It seems like it'd be helpful to stick with paths instead of rects if possible? My understanding is that gradients are very non-trivial for curved paths, but that they are relatively straightforward for straight paths at any given angle using a gradient transform. It seems to me that the branches we want to apply gradients to on any of our layouts are straight paths? |
|
I don't know best solution between |
Inferred transitions from A-B (parent-child) are now represented as colour gradients from the parent to the child (previously the entire branch had the colour of the child, which could be misinterpreted to imply that the time of the transition was known). Known issues: 1. the linear gradients are _only_ valid for horizontal lines (i.e. rectangular) trees. This will be fixed in a future commit. 2. Branch hover changes the colour & needs to be updated to use the gradient
Previously we changed the stroke colour of branches on hover. Here we extend this to handle linear gradients. Previously, the on-hover stroke colour was somewhere between the "true" node colour and the "normal" stroke colour, and varied depending on the confidence attached to the colorBy at the node. This didn't look good with gradients, so I now emphasize the previously calculated stroke colour by increasing the saturation and making it slightly darker.
jameshadfield
force-pushed
the
svg-gradient
branch
from
21d6bbf to
3e0906b
Compare
jameshadfield
temporarily deployed
to
auspice-svg-gradient-osdh09srk
|
Update:
To do:
|
If the jittering of such paths is problematic, an alternate solution is to switch the coordinate system of the gradients into user space instead of using the path bounding box. I don't think this would be troublesome to specify since I think we already know the coordinates of the branch in user space. Jittering may be simpler though if it doesn't cause other issues. |
|
I don't know if this is helpful, it seems like a complex solution but could be helpful: another idea for the rectangular version would be to simply render a circle under the intersection to smooth things out a little bit |
|
@enjalot all the paths to have gradient applied are straight, so "normal" SVG gradients work (and are working in this PR) as long as the line isn't perfectly vertical / horizontal. |
|
PR superseded by #947 |
|
Closed by the merge of #947 |
See #896 for intention.
This requires using SVG
rectangles for the branch stem as gradients are overly complex to add topaths. As such, lots of things are broken (e.g. all layouts except rect), and some functionality (branch hover colour changes, branch click to zoom) is disabled here.I think it looks really good, but wanted to discuss this before we commit to cleaning up the code so that previous functionality is restored. cc @trvrb @rneher