archaeopteryx 3.5.0 → 3.6.0

package/README.md

@@ -296,8 +296,11 @@ so every branch and position is scored by how far the tip pairs' ancestors
 fall from that halfway point, and the root goes where that deviation is
 smallest [1]. It has been compared with other rooting methods on prokaryotic
 gene families [2]. It needs branch lengths and at least three tips, and is
-offered only then. The algorithm is the desktop Archaeopteryx's, and gives
-the same roots; it runs in O(n²) time and O(n) memory (the 13,246-tip H5N1
+offered only then. Tip pairs closer than 1/100,000 of the tree's diameter
+(identical sequences, or FastTree's 5 × 10⁻⁹ stand-in for a zero branch) are
+left out of the deviation sums: their deviation measures noise, and summing
+it would swamp the precision of all the others. The algorithm is the desktop
+Archaeopteryx's, and gives the same roots; it runs in O(n²) time and O(n) memory (the 13,246-tip H5N1
 demo tree roots in 0.4 s, measured in Node).
 
 Every internal branch then carries its **MAD value**: the root-mean-square
@@ -630,17 +633,19 @@ viewer.destroy();          // unmount COMPLETELY: the container DOM, the node
                            // handler; a later launch() works normally
 ```
 
-**Big trees draw on the next frame.** Above 3,000 nodes, `launch()` does all
+**Big trees draw on the next frame.** From 5,000 nodes, `launch()` does all
 its validation, shows a "Drawing N nodes" card over the tree area, and
 returns within milliseconds — the label analysis, visualization candidates,
 control panel and the draw itself all run one frame later, so the browser
 can paint the card instead of appearing frozen for the seconds a large tree
 takes. Every error still throws synchronously from `launch()`
 exactly as before; only the draw is deferred. `viewer.ready` resolves when it
-has run (immediately for a small tree, which stays fully synchronous). Later
-redraws on a big tree — a checkbox, a slider, a search — work the same way:
-they show a "Redrawing" card and run on the next frame, and every redraw
-requested in the same tick collapses into one. Wait on `ready` before reading
+has run (immediately for a smaller tree, which draws synchronously). Later
+redraws — a checkbox, a slider, a search, the mouse wheel — run on the next
+animation frame for a tree of any size, and every redraw requested before
+that frame collapses into one: a wheel flick is one redraw, not one per
+notch. A "Redrawing" card appears only when the tree's previous redraw took
+300 ms or more on the computer it runs on. Wait on `ready` before reading
 the tree's DOM after `launch()`:
 
 ```js