Improvements to flight and navigation performance for polytomy view

[jrosindell]

Currently it’s using a linear zoom which doesn’t always feel it’s tracking the path towards a location.

We're worried about a jittery solution that makes people feel seasick

Perhaps the solution is to mostly zoom out without panning and then smoothly transition to pan near the end.

[jrosindell]

Possible extension - flights from one leaf to another with mostly zooming out then smooth panning then mostly zooming in

[lentinj]

I'm struggling a bit converting this into code changes. There seems to be a selection of flight methods in the controller:

• perform_flight_animation is useless unless you are mostly zooming in or zooming out, since it seems to track across the tree at the same zoom level. Comments seem to suggest this is known
• perform_flight_transition is completely broken, relying on a now-removed get_common_ancestor()
• transition_animation seems to work, but isn't actually used anywhere.

What in particular are we trying to fix? Seems like plotting a course between ~10 nodes along the path in transition_animation would be easier and more generically solve the problem. Although maybe this is what we thought would make us seasick.

In addition many attempts in polytomy view result in Uncaught TypeError: Cannot read property 'is_interior_node' of undefined. I'm guessing this a good place to start, even if it isn't the main event of this ticket.

[lentinj]

Naziha also wants the quick links to be in flight mode.

[jrosindell]

I think perform flight animation is what you want to fix first.

perform flight transition was for zooming from leaf A to the common ancestor of that and leaf B and then to leaf B - this is the only sensible way to get from A to B more generally.

If the transition from a leaf / node to a node higher in the hierarchy could be got working in a smoother way, and similarly from a node to a descendent of some kind (the other direction of the above) then anything else could be strung together by seeking common ancestors. You'd need to pause for a moment on the common ancestor before zooming in to leaf B but that's probably overall better than building something that does the whole path entirely smoothly which would certainly be more complex. That would enable perform flight transition to be fixed which will be needed for what Naziha wants...

I think the reason why flight transition is not in operation is that no current UI features demand the function so it was never kept working. You will need perform flight transition because you need to find the common ancestor of the current view of the tree with the place you're wanting to zoom to - then zoom to that ancestor before zooming in again on the desired place. This is the only way to get a nice fight to e.g. birds if you are already zoomed deeply into primates - you must zoom out to amniotes and then in again to birds as two separate stages with a short pause inbetween.

To make the quick links be in flight mode (or have a switch of some kind) should be pretty easy and entirely doable from the UIKit part of the code over the OZtree JS package. Essentially you just need to switch the jump_to_OZid for perform_flight_transition when the latter is fixed...

Sorry it's a bit complex!

[lentinj]

The above is starting to work, although temperamental:

• Very close-range zooms are backing up too far
• Zooms that require re-anchoring are linear, and restart the acceleration profile after re-anchoring moves are done.
• No images are loaded during flights.

[lentinj]

Moths seem to be a particularly nasty case that reduce rendering to a crawl. It could be mitigated to a certain extent, but I'm not sure what can be done in general.

[lentinj]

@jrosindell I seem to remember that there are parameters that control loading of detail whilst in flight mode, but I can't find them. Do you remember where to look?

Currently flights in look very bare as a result.

[jrosindell]

I have a memory that all the details are pre fetched before the flight begins - this is so that the flight is guaranteed to be of reasonable quality and smoothness. This makes me think that it's a consideration for more complex flights too which should prefetch the tree for the whole flight (i.e. the zoom out part and the zoom in part of a more complex transition). Hopefully this helps - I don't recall precisely where to look off hand and am writing in a hurry but will look again later.

[lentinj]

I have a memory that all the details are pre fetched before the flight begins

Yes, they are. Without it wouldn't know where to go.

I think I've seen something in the rendering pipeline that reduces detail to cope with flights, which would solve all my problems. I must be able to find it again :)

[lentinj]

Okay, when I said "they are", apparently I was confusing developing nodes and fetching their details. I presumed that developing nodes also meant we would fetch the detail. That's not the case.

fetch_node_detail() is disabled during flight, re-enabling solves our problems, but can't be the way forward.

But I've found another flight mechanism, fly_to_node here: https://github.com/OneZoom/OZtree/blob/master/OZprivate/rawJS/OZTreeModule/src/navigation/page_loading.js#L11 get_details_of_nodes_in_view_during_fly() I'm guessing is what I want.

[lentinj]

Okay, so the above:

• Guts page_loading.js, and moves the logic into controller_anim.js, which is a more sensible home for it.
• Uses get_details_of_nodes_in_view_during_fly() to load everything required for perform_flight_animation.

There's lots of commonality between the various code paths, ideally there'd be just one but I think that's a task for another day. Specifically when organising the tours, since then transition_animation()'s fate can also be decided.

[jrosindell]

Thanks Jamie - I've been looking on your Shuttlethread hosted version and see that something has changed they look smooth and I definitely saw a smoother zoom in some cases but it’s not clear which functions have used improved zoom and which functions have not yet. In particular, I don’t think panning and zooming have been decoupled yet and this was going to be part of the plan to have more logical paths to the destination. At least it doesn't look as though they have.

[lentinj]

I don’t think panning and zooming have been decoupled yet

See here:

https://github.com/OneZoom/OZtree/blob/3.3/OZprivate/rawJS/OZTreeModule/src/position_helper.js#L337

There's separate functions for pan and zoom, pan ramps up half-way through the first zoom, then back down again in the second. Zoom OTOH accelerates and decelerates the same on the way in and out, giving a rest at the final location.

For example: onezoom.controller.perform_flight_transition(-835084, -796335) you see it zoom out from the elephant, then just as the elephant picture goes out of zoom it moves off to the right.

However, on long zooms where there's reanchoring it's still linear (onezoom.controller.perform_flight_transition(-835084, -294475)), because the number of steps isn't known. However, if such re-anchoring animation steps just zoom, then the end result is fairly similar, if a little more crude. I'll change that.

[lentinj]

@jrosindell As part of looking at what one might want to change in #139 for an improved rendering mode, I've done the above.

The first few sort out the giant nodes above, which whilst we marked non-essential are really obvious in flight views, and are going to result in questions. So I fixed it.

As a result of this, it was more obvious my fake fans weren't centered, so the third fixes that. On long flights you now get the impression of the tree growing which is quite nice.

Finally, the values I was trying to loosen actually aren't so critical, thanks to previous work in this ticket, so I've just loosened them for all views.

[lentinj]

(hrm, I never submitted this comment from yesterday)

@jrosindell As part of looking at what one might want to change in #139 for an improved rendering mode, I've done the above.

The first few sort out the giant nodes above, which whilst we marked non-essential are really obvious in flight views, and are going to result in questions. So I fixed it.

As a result of this, it was more obvious my fake fans weren't centered, so the third fixes that. On long flights you now get the impression of the tree growing which is quite nice.

Finally, the values I was trying to loosen actually aren't so critical, thanks to previous work in this ticket, so I've just loosened them for all views.

[jrosindell]

Thanks @lentinj this is looking a lot better. Having played with it for a while I see that the flights are smooth (on both my iPhone and laptop). Let's see what the other testers have to say. Meanwhile, there are a few issues remaining still.

1.) the images on signposts no longer load in advance of the flight animation starting so that actually one can get a flight with no images at all. This happens especially when visiting a URL with ?init=zoom. This includes an issue that seems new to me where the circular borders around an image get loaded on the ordinary OneZoom view at times when the image itself is not loaded.
2.) the logic around clicking on signposts to zoom in doesn't seem to use the same (efficient) flight logic as the search and popular places.
3.) the normal view (non polytomy) is still not what it was before in terms of the fake leaves - they are still large and grey, rather than smaller, leaf shaped and green.
4.) (lower priority as at some point I guess it will be impossible to go further) the popular places area for mushrooms continues to have not great performance around the (giant) polytomy.

[lentinj]

4.) (lower priority as at some point I guess it will be impossible to go further) the popular places area for mushrooms continues to have not great performance around the (giant) polytomy.

26c8268 made this slightly worse again by loosening the restrictions that made it work. My hope is that the remaining issue in #108 will get around having to tighten these restrictions again.

[lentinj]

3.) the normal view (non polytomy) is still not what it was before in terms of the fake leaves - they are still large and grey, rather than smaller, leaf shaped and green.

There's 2 problems:

1. The large grey "baubels" are created by branch_layout_helper:draw_interior_node. The attempt to hide the line joins is going wrong (ooo look, another case affected by a miscalculated arcr).
2. But whereas before they would have been covered by a leaf (thanks to the above bug it was assumed these were leaf nodes when fake), they're now exposed.

I'm not entirely decided how to fix this. the first may be solved by #143, but we need to put this explicit decision that fake nodes with children get a leaf somewhere regardless.

[lentinj]

2.) the logic around clicking on signposts to zoom in doesn't seem to use the same (efficient) flight logic as the search and popular places.

It's the same code-path, just with a linear acceleration function. You can accellerate into the signpost but it seems a bit silly on the small flights that you do.

[jrosindell]

2.) the logic around clicking on signposts to zoom in doesn't seem to use the same (efficient) flight logic as the search and popular places.

It's` the same code-path, just with a linear acceleration function. You can accellerate into the signpost but it seems a bit silly on the small flights that you do.

What I mean is not so much that I'd like an accelerating fancy flight path for such a short journey, but rather that the outright performance is poor for some reason, jerky unlike the longer flights.

[jrosindell]

I'm leaving this issue open because the polytomy view on the main side (not on OTOP) has quite poor performance compared to the polytomy view on OTOP. It would be great to look again at the performance issues, particularly for the main site polytomy view. https://www.onezoom.org/life/@=93302?vis=polytomy&img=best_any&anim=flight#x672,y1468,w3.2739

I'll add that this isn't just about the flights - it's also about navigation performance.

[lentinj]

Do you have a particular example here? My standard -> "Elephant Hawk-Moth" -> "Elephant" -> ... is looking like it gets just as many frames as OTOP under Chrome.

Navigation zoom performance is a harder problem anyway since content is being loaded on the fly, which both makes it harder on the system and harder to have a consistent test, but doesn't look obviously broken.

What however does look obviously broken is the size of some of the signposts whilst flying to the elephant hawk moth. The massively branching nodes seem to be an edge case the visibility parameters aren't covering.

[lentinj]

@jrosindell You said you were going to see if the publication correction had a particular example? Failing that if you have a chance to find something that is failing predictably then I can have a look. From memory the worst case is loading a page whilst already zoomed into something and zooming back out. However, it could have been they tried something like that and just didn't have the network bandwidth to make it work smoothly.

If we don't have a reproducible example, then I'll compare OTOP and polytomy setups to see if there's something that could be copied over.

[hyanwong]

All that the reviewer said was:

I was pleased to see that the interface in OneZoom provides the user an option to display "polytomies", and what a difference that makes! Large polytomies are rendered as semi-circular fans, which changes the look and feel of the tree in places quite significantly. However, for large polytomies it can dramatically slow down rendering speed compared to the binary tree rendering mode. This detracts from the otherwise exceptional experience provided by the code. One approach to fixing this would be to render a translucent semicircle with no edges per se, until the zoom level warrants display of actual edges.

The only other comment I can find related to polytomy navigation is this:

Related to that, tree navigation using mouse-dragging does not always work flawlessly, especially not in the polytomies projection. If one tries to explore a clade and move along a longer branch, one gets stuck once no nodes are visible anymore.

[lentinj]

However, for large polytomies it can dramatically slow down rendering speed compared to the binary tree rendering mode.

Yeah, compared to binary trees (vs OTOP) it's going to be slower, can't avoid that.

One approach to fixing this would be to render a translucent semicircle with no edges per se

Indeed, already do that. There's plenty of thresholds to tweak though, which could be an answer. From memory these are different OTOP vs. Polytomy. OTOP the thresholds are turned further down (I think) to make up for the resource-intensive glow behind each line, animated backgrounds, etc.

If one tries to explore a clade and move along a longer branch, one gets stuck once no nodes are visible anymore.

This is interesting, the tree tries to stop movement in a direction where there isn't to see. So if you somehow manage to move into empty space, it's possible to get stuck. However, I didn't think this was possible any more.

[jrosindell]

If one tries to explore a clade and move along a longer branch, one gets stuck once no nodes are visible anymore.

This is intended behaviour so people don't get lost - the user isn't allowed to navigate into a position where there are no nodes on the screen. I did not include the branches in the code for this because I wrote it before the polytomy view was a thing. It would be nice to fix it but I think it might require a fair bit of effort so I'd suggest a lower priority on that part.

OTOP the thresholds are turned further down (I think) to make up for the resource-intensive glow behind each line, animated backgrounds, etc.

@lentinj, when I added this issue I intended primarily for you to just ensure that the OZ polytomy view has the same optimisations as OTOP (even though no glow, backgrounds etc). You can probably ignore the other issues. Strangely, when I tried to replicate this I found it to be quite smooth even though I have a memory of it being very slow when I opened the issue.

[lentinj]

Strangely, when I tried to replicate this I found it to be quite smooth even though I have a memory of it being very slow when I opened the issue.

It could have been your network connection at the time, zooming out in particular can suddenly make a lot of detail/image requests. If the roundtrip is slow, then the tree view will get very sluggish. You could try throttling your connection with the browser developer tools and see if it's similar to what you remember.

[jrosindell]

I tried throttling and couldn't get any issues. I think we can close this soon, but one thing does need to be looked at, when the centre of nodes goes off screen with polytomy view, the whole node disappears. It should be only when the edge goes off screen (as is done with the classic spiral view).