OneZoom / OZtree

OneZoom Tree of Life Explorer
Other
87 stars 18 forks source link

Zooming into high-branching areas painfully slow #108

Open lentinj opened 6 years ago

lentinj commented 6 years ago

Mushrooms currently cripple the polytomy view. The normal tactics of restricting depth aren't enough.

jrosindell commented 6 years ago

I wonder if this is a situation where solid semicircles could be rendered up to a point.

Also, I think it's worth looking at the thresholding code - that is the threshold of shape size that results in the shape getting drawn or not. This threshold is (I think, unless it's changed) set by benchmarking before the system starts and then dynamically adjusted to keep the frame rate high. A bug in this code could easily cause a lot more CPU cycles to be required - it's also strange the way the tips of the tree flicker due to dynamic changes in the threshold. I think it's worth looking at solutions to this alongside the high branching nodes. Also, a small tweak in the threshold or the interpretation of the threshold could make a big difference to rendering cost even if there is no actual bug in that part of the code - so maybe worth experimenting with?

lentinj commented 6 years ago

The problem is (IIRC) the thresholds affect depth of branch generation, gaining more speed by not bothering to generate after so many steps down. In this case, there are (basically) no steps down. Mushrooms all fan out from a single node, so even if depths have turned to 1 then this won't help anyone.

Drawing a semi-circle would probably speed up the situation (I've not done any profiling on this yet), but that then looks very broken if you are zoomed in enough to see a handful of mushroom children.

jrosindell commented 6 years ago

How about rendering the most species rich children individually and then adding a 'wedge' of solid colour for the remainder of the fan where the lines are so close that it looks solid anyway?

jrosindell commented 6 years ago

You can see here how it wouldn't matter to render a wedge. I have also wondered if the ordering of child nodes should be tweaked so that the largest group is in the middle rather than on the far right - but that's a separate question.

untitled4
lentinj commented 6 years ago

Depends what profiling actually shows is slow. Id guess it's not the low level rendering of the lines though, and I'd rather not add the special cases to draw the above as mostly-semicircle-but-some-normal.

jrosindell commented 6 years ago

This is what I'm talking about re. the leaves and thresholds - it is not related to building the tree itself in tree factory it is related to the size of tree sections that allow rendering to be triggered vs. drawing fake leaves instead. This screenshot also from mushrooms shows how the edge of the tree looks a bit strange....

untitled3
jrosindell commented 6 years ago

I meant to post the above before your reply but left the window open without pressing comment - sorry. In terms of the optimisation I'm of course happy for you to do whatever you think the most fruitful way to improve performance. Overall, I think catching these special cases and making them render smoothly in some kind of manner is more important than preserving an optimal appearance of them - a solid semi circle wouldn't be too bad until zoomed in a bit more but maybe that's not enough to solve the problem, as you have said.

jrosindell commented 5 years ago

We discussed with Naziha fixing this by using solid filled semicircular sprites that render as lines only when zoomed in. Also the tree factory should (for very large polytomies) not attempt to expand any of the children at all until the polytomy is quite zoomed in.

lentinj commented 5 years ago

Right! The above:

The end result is pretty smooth animation from Field Mushroom to Blackberry, which in both directions is pretty pathological. We possibly sacrifice slightly more accuracy than necessary, but I'm not testing on the lowest of low-end devices.

Performance if you load the page from Field Mushroom still isn't great, but that's developing all the nodes around (which the zoom has pre-generated).

lentinj commented 5 years ago

@hyanwong noticed that zooming out is causing bare leaves on the default spiral view, see https://github.com/OneZoom/OZtree/issues/122#issuecomment-421248934

jrosindell commented 5 years ago

Forces fake leaves for nodes that have many children vs. it's size

Adds a "Fan" fake leaf style if we're zoomed in to a fake leaf, that generates only one shapes object vs. one per branch.

I agree these were necessary and good things to do but I wonder if they are responsible for the fake leaf bugs we've seen emerge specifically during flight (rather than during exploring) where fake leaves are drawn as circles for the life view and the OTOP view when really a fake leaf shape and a fake fan shape respectively would be more appropriate.

jrosindell commented 5 years ago

There are some further issues here that I just discovered. Another example of a painfully slow polytomy is Cyanobacteria. screenshot attached of an example where it gets slow as you zoom in on the node enough to draw all the lines instead of the fake fan.

jrosindell commented 5 years ago

cy3

This is the part that has performance issues

jrosindell commented 5 years ago

Interestingly - if I look at the same node in /life with ?vis=polytomy the performance issues doesn't seem as bad.

jrosindell commented 5 years ago

There is a layout bug as well on this node which appears when the parent node is moved off the top of the screen - an unwanted line appears (see below pair of screenshots)

cy1

EDIT: Moved to https://github.com/OneZoom/OZtree/issues/143

jrosindell commented 5 years ago

cy2

lentinj commented 5 years ago

Interestingly - if I look at the same node in /life with ?vis=polytomy the performance issues doesn't seem as bad.

There's 2 reasons for this; the shadowBlur on branches in OTOP is hard for a browser to render, and the background will already be grabbing a bunch of CPU.

Another example of a painfully slow polytomy is Cyanobacteria

This is identical to the problem reported in #91, and is similarly mostly solved by it (arguably that work should be here, not in #91

jrosindell commented 5 years ago

Thanks @lentinj. I still think that there is a problem around these areas when you zoom into the node at the centre of a fan. What happens is that it gets to a level of zoom where it's judged all the lines need to be rendered, but because the centre of the node is on screen none of the lines can be left out of the rendering because they all interest with the viewport. I suggest that the test for whether to put a sprite or individual renderings should be sensitive to whether the tips of the fan are in view or not.

lentinj commented 5 years ago

I suggest that the test for whether to put a sprite or individual renderings should be sensitive to whether the tips of the fan are in view or not.

It's nothing to do with rendering, JS can get through that pretty quickly, even faster now I've turned off shadowBlur for high-branching nodes.

The main culprit at this point is split_string_and_record_in_cuts(), which is filling in gaps in the pregenerated generate_polytomy_cut_position_map() DB. I suspect unravelling the recursion and plowing through the brackets once is the way to go.

jrosindell commented 5 years ago

This looks good @lentinj - the performance is much improved.

I think we could almost close this, but for now I'll just relabel it as nice to have because the essential components have been done now I think.