Comment 21 for bug 1795135

Created attachment 136979
Fix

After 4 hours of debugging a totally unknown source, here's a fix that works for me. Could you guys please test it?

It's against 1.19.5 because I recompiled my distro's packages and that's the version my distro ships. I hope it still more or less applies against git master.

There are two things to the story, and I think either segment of my patch fixes the issue, but it's probably better to have both parts in place.

One is an ugly use of trunc() instead of floor(). trunc() rounds towards zero, and as such, with slightly negative (temporary??, before clamping??) mouse coordinates, root_x_frac becomes negative (e.g. a value of -0.6 is stored as root_x = 0, root_x_frac = -0.6, as opposed to root_x = -1, root_x_frac = 0.4 which would be the logical, following the pattern of the rest of the code with the FP1616 and FP3232 data types).

Another is that at certain places, root_x is set to a certain value, but root_x_frac remains unchanged, still containing the previous value. This is probably how the previous negative fraction can leak to places it shouldn't.

[Same for root_y and root_y_frac, of course.]

My patch (especially this latter part, resetting root_x_frac whenever root_x is set) may not be complete, and I have a slight feeling that my patch still doesn't address the real root cause. I'm not sure about it.

Meta:

I think I've done my fair share to fix this issue, I won't have any more time to work on it. Douglas, Adam, could you please nag the devs on mailing lists and such if they don't notice this patch here in a reasonable time? It should be a piece of cake for them to polish this up and commit based on my findings.