This fixes the following problem:
When automation lines with significant change are zoomed in time, the
slope gets smaller (towards horizontal) as the control points moves
further away from the visible area. That was rendered correctly, but the
corresponding mouse events happened as if the line had a steeper slope.
The problem was caused by the X value being clamped to the visible area,
without scaling the Y value correspondingly. It has apparently been like
that for a decode, since introduced in c4f0063a68.
The problem is fixed by introducing a clamp2 function that scales the Y
value if clamping the X value.
Note: An old comment says that math goes wrong unless clamping below
COORD_MAX. It is not clear to me what math it refers to, and especially
why we don't need similar clamping on the lower bounds.
And while rarely a real problem, I guess it would be more correct and a
slight optimization to skip all lines where both ends are outside the
same bound. In theory, as it is now, the mouse could catch an invisible
line close to the border.
d1265b5a02
