Say where you are: a rail for rows, a dial for the disc

[Paururo]

On a tree of two million tips a wheel notch will take a reader to seven rows and
nothing on the canvas says so. Fit is the only way back, and it throws away where
they were. This adds the rail: the whole tree, at the height of the canvas, down
the right hand side, with the rows on screen marked on it.

It cannot disagree with the tree

The rail is drawn from the same select the main view is drawn from, over the
whole row range instead of the window, at the canvas's own height. That is the
point of the first commit here, which lifts the choice of what to draw out of the
middle of drawing it: with one selector there is no second opinion to have. It is
built once per load and again only if the canvas changes height, which on
2,097,151 nodes is 9,822 branches and about 1.5 ms.

Per frame it costs a re-stroke of those branches. Measured on a 500,000 node tree
at 900 by 520: a paint with the rail is 3.0 ms and panning holds under a
millisecond a frame.

What a hand can do with it

Click, drag or wheel on the rail and the window goes to those rows, keeping how
many rows are in it. Measured on the real page against the million tip demo:
clicking at 5, 35, 65 and 95 percent down the rail lands on tips 47,242, 347,242,
647,242 and 947,242 of a million, and dragging from 20 to 80 percent walks
through 197,242, 397,242, 597,242 and 797,242. Wheeling down moves the mark down
the rail and wheeling back up returns it to the pixel it started on.

A wheel on the rail scrolls rather than zooms, because a zoom there would be
anchored on the wrong row: the two sides of the canvas are at different scales.
Which side a gesture began on decides what it is for its whole life, so a drag
that starts on the rail and wanders onto the tree goes on moving the window.

The small print

Seven rows in two million is a thousandth of a pixel, so the mark is held at four
pixels and kept on the rail rather than allowed to hang off either end. Below 420
pixels of canvas width there is no rail at all and the tree gets the width back,
which is what a phone gets: verified at 375 px, where the pixels where the rail
would be come back fully transparent.

panBy grew a dx it drops on purpose, and now says so: the depth axis is
fitted to what is drawn on every paint, so nudging it sideways would be undone
before the frame reached the screen.

Checks

Eight new cases in tests/tree-canvas.test.js, which CI runs. Two of them are
there to stop the others passing vacuously: one asserts that a rail built from
the window would follow a zoom where the real one does not, and one asserts that
scrubbing to the top and to the bottom of the rail land more than 700 px apart,
which a dropped or constant mapping would fail. The fake 2d context gained
fillRect and strokeRect and now records them, so the mark's size, position
and colours are checked rather than assumed.

And the same idea, bent round

The crate has three projections and the page had one. The rail does not fit a
circle, because a circle has no top and bottom to scroll between, so the
circular view gets a dial instead: the whole disc, small, in the corner, with
the window drawn on it. Same idea, shape following the projection.

The disc is the crate's own arithmetic and not another one that resembles it.
radial.rs says a radial tree is "the rectangular one in polar coordinates: the
same rows, with depth becoming radius and row becoming angle", and the canvas
uses that formula with the crate's own defaults: the sweep starts at the top of
the circle, goes all the way round, and leaves a hole eight percent of the way
out. A check writes that formula out again from the crate's source and compares
it against where(node): the two agree to a thousandth of a pixel, and moving
the hole from 0.08 to 0.10 or the start from -90 to 0 degrees fails it.

Switching projection asks the program for nothing. The rows and depths are the
same numbers read a different way, so there is no round trip to the worker and
a check pins that the layout arrays come back untouched.

Two bounds, because a circle needs them

A million tips draws at fourteen milliseconds a frame at full extent and under
two milliseconds anywhere in a zoom. Getting there took two rules, and the first
version of the first one was wrong in a way worth recording.

Every walk heads inward, so a walk that has gone further in than the window can
see has nothing left to draw. Stopping instead on "off the canvas" seemed
equivalent and is not: a tip outside the window walking inward was cut off
before it reached the part of its own lineage that is inside it, and the picture
came out with 1,423 of its 1,430 branches off screen. The rule is a radius, not
a box.

And a branch further out than the window can see is walked past rather than
drawn. On the worst gesture, zooming into the middle of a two million node disc,
that takes 24,051 branches down to 2. Rendered pixel by pixel against the same
view without the rule, at four zooms, the ink is identical: 544,112 pixels
against 544,112 at full extent, 41,623 against 41,623 zoomed in, one pixel
different out of 5,555 at the deepest.

The sample budget is the circumference of the widest circle the window can see
rather than of the rim, which is not the same thing once the rim is off the
canvas: measuring against the rim asked for six thousand samples of a region
that holds a few hundred.

Export says --projection circular, which is a flag the crate already had.