Fix scrollbar int overflow in drag handling

[L1quidH2O]

For large files, delta_y * scrollable_height can cause an int overflow, resulting in a negative scroll_offset and broken behavior. This PR fixes it by casting to f32 for calculation.

Broken Demo:

Scroll bar doesn't make it to the end of the file and jumps back to 0

broken.mp4

Fixed Demo:

Scroll bar continues normally

fixed.mp4

[lhecker]

I'll reject this PR, because I believe it's better to change the CoordType from i32 to isize. This is needed, because we now load files up to 4GiB which can exceed the range of i32 for the line count. That should also solve this issue.

FWIW casting to a f32 may technically introduce rounding issues because it can only store up to 2^24 precisely (= 16M, as opposed to 2G for i32 and 9E (Exa) for i64).

[L1quidH2O]

I agree with changing CoordType to isize, but that does not fix this issue on 32-bit systems.
The precision of f32 concern is negligible as we are calculating ratios, which is inherently approximate anyway.
I highly suggest reopening this PR to fix the current issue.

[lhecker]

The max. file size supported on 32-Bit versions is 128MiB. It should be quite difficult to exceed the 32-Bit range with that, unless I'm thinking about it incorrectly.

[lhecker]

The precision of f32 concern is negligible as we are calculating ratios, which is inherently approximate anyway.

Oh, and what I actually wanted to say with my comment is that we should be using f64 here. On all relevant hardware, the performance between non-SIMD f32 vs f64 operation is identical after all anyway. I didn't want to say that we strictly have to use integer arithmetic there.

[L1quidH2O]

I think you misunderstood the problem, delta_y * scrollable_height is the calculation that causes the int overflow.
On my terminal, when fullscreen and at the default zoom, delta_y reaches about ~39, but it can be even higher if I zoom out.
If we assume a scrollable_height at around 128MiB, scrolling would break at delta_y = 16.

[L1quidH2O]

I've updated my branch to use f64 as advised if you'd like to reopen.

[lhecker]

I did understand the problem, but I forgot that delta_y doesn't refer to the scroll delta which is limited to +3/-3.

[lhecker]

FWIW I still don't particularly like the usage of f64 there. It's not consistent with any of the other places. Personally, I'd either want everything to use f64 for intermediate fractional calculations or none of them.

Of course, fixing this bug takes priority though.

[lhecker]

I should also say that I'm grateful that you corrected me. I apologize that I made it difficult.