bug#66247: 29.1; Transient frame problems with Emacs 29 on MS Windows

[Drew Adams]

> I see the same in Emacs 28, so this isn't a regression in Emacs 29.
> When Emacs needs to redraw the frame, it actually asks the MS-Windows
> GUI subsystem to do that, and the update takes time (and happens in a
> separate UI thread).  So these small lags are expected.

You're right about that.  So that simple recipe
isn't good enough.

I'm guessing that you're also right about the
only problem being the double-buffering.  I'm
guessing that for some reason things are just
somewhat slower in Emacs 29 for frame display,
so I notice the lingering scroll-bar position
more.

I think you can close this bug, the general
solution being to add (inhibit-double-buffering . t)
to `default-frame-alist'.
___

BTW, what's the rationale behind making this
a frame parameter rather than just an option
that affects all frames?  Presumably there is
some use case for having it ON or OFF for only
specific frames or groups of frames.  I'm
curious what such a use case might be.

Because of this choice, I need to customize
both `default-frame-alist' and
`special-display-frame-alist'.  (I know that
Emacs considers that option to be obsolete,
but it's very important to me.)  There are
other frame-display alists, as well, and
users might have still other alists governing
different groups/types of frames.

Again, I imagine there's a use case for this
frame parameter to be a frame parameter, as
opposed to just an option that affects all
frames, but so far, I can't imagine what such
a use case might be.