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

[Eli Zaretskii <eliz@gnu.org>]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "luangruo@yahoo.com" <luangruo@yahoo.com>,
>         "66247@debbugs.gnu.org"
> 	<66247@debbugs.gnu.org>
> Date: Mon, 9 Oct 2023 18:33:48 +0000
> 
> In addition to the problems described, even when
> parameter `inhibit-double-buffering' is `t':
> 
> When applying a set of frame position and size
> modifications, the transient appearance shows
> not only the scroll bar in the initial position
> but the overall frame, even after it's resized,
> remains in the original position.  The final
> position and location of the scroll bar are not
> realized at the same time as the frame is resized.
> 
> There is a _general_ regression wrt the behavior
> in all previous Emacs releases (back through 20,
> at least).  Setting `inhibit-double-buffering' to
> `t' removes only some of the problems introduced.
> 
> You may say that the rest of the frame-display
> implementation, besides the addition of double
> buffering, wasn't changed for Emacs 29, but that
> doesn't seem to be the case.  Something has led
> to a regression wrt frame display - multiple
> frame parameters.

Needless to say, I see none of this on my system.  But since you
didn't post any information regarding how to reproduce this, not even
which commands and/or functions are used when this happens, it is hard
to tell whether it simply doesn't happen here or you do something that
I don't.

> When a set of parameters are changed with one
> `modify-frame-parameters' the effect is not to
> change them all at once - and that's new (a
> regression).  The frame is resized, and some
> time later the other frame modifications take
> effect.

Frame parameters were always applied one by one in Emacs, not
together.  This is not a regression, this is how Emacs always worked.

Bottom line: I find such "bug reports" extremely frustrating, because
nothing, literally nothing, can be done about them without extra
details.