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

[Drew Adams <drew.adams@oracle.com>]

> > 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.

Yes, as I said, I'm sorry I don't have the time
needed to dig into this in detail.

Here's a simple recipe from emacs -Q that should at
least enable you to see the lag in display of the
scroll bar.  It's not kept contiguous with the frame
edge as you move that edge out.

emacs -Q

M-x customize-option default-frame-alist

Add an entry for inhibit-double-buffering as t.

Set the option value for the current session.

`C-x 5 2' or in some other way get a new frame,
so `default-frame-alist' kicks in.

Grab the right frame edge with your mouse and
move it to the right.  I see a lag: the scroll
bar stays where it is briefly, then finally
catches up with the new position of the right
frame edge.

The inhibition of double buffering removes
the display of a black background between the
initial position (and lagging display) of the
scroll bar and the new position of the right
frame edge.  But it doesn't remove the lag
in positioning of the scroll bar adjacent to
the right frame edge.  There's still a
transient visible gap; it just no longer has
a black background.

The faster you move your mouse to the new
right-edge position the wider the gap.  IOW,
the correct redisplay seems to occur after
the same time duration, so the greater the
distance between the initial and final right
edge positions the wider the gap you see.

The bug report specifies the Emacs build I'm
using.  Dunno whether the problem is just with
that build.  If it is then maybe you won't see
the problem.

HTH.