Set a maximum value for line width; add more granularity; normalize to tree dimensions

[fedarko]

In practice, increasing the line width by 1 is a really big increase. In my opinion, it would be desirable to cap the line width at ~3, and then make the interface support smaller increases (e.g. by 0.1, or even keeping things as integers but scaling them by 1/10 or something), so that increasing the line width doesn't feel so sudden. (When you get up to line width = 3, it becomes really hard to see what's going on in the tree, especially when you zoom in.)

Below are screenshots of line widths = 1, 2, 3 for the two layouts. For each of the layouts' sections, I kept the camera at the same place for all 3 screenshots.

unrooted

Line width = 1:

Line width = 2:

Line width = 3:

rectangular

Line width = 1:

Line width = 2:

Line width = 3:

[ElDeveloper]

Great suggestion @fedarko, increments of 0.1 sound like a good idea.

[kwcantrell]

I think this issue mainly stems from how the line width are calculated. Currently, the line width are created by creating a rectangle of width 2*line_width (in tree space). So, a line width of 2 will appear smaller or larger depending on how much space is spanned by the tree.

see https://github.com/biocore/empress/pull/145/files#r401141659

[fedarko]

From @kwcantrell, emphasis mine:

Originally, I defined a line width of 1 to be equivalent to "0" i.e. the branches are just colored. This is why SidePanel._updateSample() would call lwidth - 1 since a "line_width" of 1 is really a line width of 0. However, I think it would be better if we account for this operation in thickenSameSampleLines instead of relying on the caller to account for this.

Also, lines 436-9 is what I was referring to in my comment in #144 when I said line width are "created in tree space".

To create the "thickened" lines, the goal is to create a rectangle (made up of two triangles for webgl) of width 2 * lwidth centered on the original branch. But if you notice, for example, the y component of the triangle is defined as this.getY(this._treeData[node]) + amount. Here, we are adding "amount" to the y-coord of the tree. This will result in rectangle (centered on the branch) of width 2*amount. However, because we are adding amount directly to the y-coord itself with out taking into account the camera/tree size, a line width of 2 will appear large/smaller depending on how large the tree is. For example, say we have tree t1 whose y-coords are in the range [-1000, 1000] and t2 whose y-coords are in the range [-100, 100] a line width of 2 in will appear 10x larger in t2 than in t1. To fix this, we need to first normalize "amount" so that a line width of 2 will proportionally take up the same amount of space in t1 as it would in t2.

[fedarko]

From discussion with @kwcantrell and @ElDeveloper, it sounds like one way to do this is computing the area of the tree display for a given layout and then scaling the line thicknesses to some proportion of that area -- say, 1/1000th of the area. It would be ideal to make this clear to users in a tooltip next to the line width selectors (#138), so that they'd have a clear understanding of what a unit of "1" or "2" means. (This would be a good time to adjust the line width stuff so that 0 means no extra thickness, 1 means an extra thickness of 1, etc.)

Things to look into:

• centerLayoutAvgPoint() in empress.js, which could be modified to compute the max and min x and y coordinates of the tree for a given layout
• This function in Emperor, which does scaling in a similar way (albeit for text sizes)

The ideal thing would be using a more straightforward "unit" than A/1000 (e.g. pixels), ... but it seems like doing that in WebGL would be more trouble than it's worth. Maybe?

[ElDeveloper]

Closing in favor of #276 since many of the issues here were already addressed.