bug#66769: 30.0.50; pixel-scroll-precision-mode and scroll-margin regression

[Eli Zaretskii <eliz@gnu.org>]

> From: Po Lu <luangruo@yahoo.com>
> Cc: aaronjensen@gmail.com,  66769@debbugs.gnu.org
> Date: Sat, 28 Oct 2023 16:34:17 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > And what are the problems in computing this target point in the
> > particular case described here?
> 
> It should be outside the scroll margin, so additional layout
> computations must be performed after scrolling, compounding those
> performed beforehand to establish the new window start.
> 
> > Even if it's done "only in this case"?  It should slow down only this
> > case, no?
> >
> > And what exactly is the crucial difference between "this case" and the
> > other cases, where scrolling works correctly?
> 
> The distinction is that scroll-margin is set.

That's what I thought, and which is why I asked whether calling the
slow posn-at-point only when scroll-margin is non-zero wouldn't be the
proper solution, as it should only slow down scrolling for those users
who set scroll-margin.  Or what am I missing?