The keyboard zoom's modifiers are not the wheel's, and that is deliberate: on common layouts + is Shift=, so a bare zoom-in already arrives with Shift set and Shift could not mean anything. Ctrl/Alt mirror the box-zoom drags instead.

A pinned view is navigable within its own data but cannot leave it. While an event is held, a capture is filling, or the view is paused, a zoom in works normally — "not outside the event" is not "not readable" — but a pan or a zoom out is clamped to the data.

Nothing you do on the plot changes the time window — only the header control does. A zoom or a pan moves the view inside the window; f (and Fit X axis) is the undo of a zoom, so a 2 s window zoomed into reads 2 s again. The window is more than the axis: it is also the trigger's event span and how the samples are stored, so a wheel notch that redefined it would re-plan the buffer and drop your history.

The axis does not scroll — the data does. A live axis is a fixed [-window .. 0] with the newest sample at 0, so the labels stand still and the trace rolls under them. The cursors stand still with the labels (they are positions on screen, so a cursor you placed stays where you put it, over newer data each frame), while a measurement's marks travel with the sample they measured and leave the view when it does.

A live view is clamped to the window you asked for, not to what the ring happens to hold. That is why a buffer that has only just started filling leaves its left-hand side empty instead of squeezing the window down to the first few samples.

Zooming hard into a held capture is exact. The renderer finds the visible samples by binary search over the real timestamps, never over a nominal sample grid, so a capture whose clock wandered does not drift away from its axis as you zoom.

A trace holding far more samples than the plot has pixels is drawn one pixel column at a time: each column is a single vertical line from the lowest to the highest value that falls in it. Drawn as a polyline instead, such a window puts three or four near-vertical lines in every column at slightly different sub-pixel positions, and how they overlap beats against the pixel grid — which reads as bands of light and dark that crawl as you pan. One line per column removes the beat, and it is also much faster: a 1 MS/s view costs a couple of thousand line segments a frame instead of a couple of hundred thousand.

Those columns are graded by brightness, the way a digital-phosphor scope reads: bright where the signal spent its time, faint where it only passed through. A column's highest and lowest value are the same whether the samples in it are spread evenly or piled at its two ends, so the grading is what tells the two apart — the flat parts of a square wave come out solid and the edges between them faint. It is read from a finer division of each column rather than from the line that is drawn, and it costs about a millisecond a frame.