bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Eli Zaretskii <eliz@gnu.org>]

> From: Antoine Levitt <antoine.levitt@gmail.com>
> Cc: larsi@gnus.org, 8355@debbugs.gnu.org
> Date: Fri, 11 Dec 2020 09:35:20 +0100
> 
> > If the changes I installed don't improve things considerably, perhaps
> > I should revert them?
> 
> It's still better than the previous behavior so I would keep it. But the
> question is what is the correct thing to do. 

OK, thanks.

> I know nothing about how it's implemented, but I would assume a simple
> round-to-nearest should do the trick, at least a very high fraction of
> the time?

That's what I did, or at least I thought I did.

> So you've got a set of integers (the pixel positions of the
> line), a current integer (the current line) and you want to move to
> another integer in the set, approximately by some prescribed amount n
> (the screen height). If you do the simplest thing which is to move by n
> and round to the nearest line, then if you go down once and up once the
> only way you can fail to come back to the original point is if the shift
> you applied to round to a line is larger than the half-separation
> between lines. So if I have lines of about 20px, I would expect that to
> happen maybe 10% of the time; and I would also expect that sometimes the
> line shift is up and sometimes down. But in my tests, even with your
> patch, I see it happening a lot more than 10%, and always in the same
> direction (going down then up shifts one line up). So either it's
> something to do with the pixel distribution of my tex files which is
> messing this up, or I misunderstand the algorithm.

A reproduction recipe for where you see this happening more that will
be appreciated.

I also don't understand how you arrived at the 10% figure.  Can you
elaborate?