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

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

> > > It is expected that it will cause a regression on some systems, which
> > > is why the way to disable double-buffering is in NEWS.
> >
> > Yes, good.  But as I explained, that doesn't fix
> > all of the problems introduced.  See what I said
> > about the delayed correct rendering of the frame
> > edge and scroll bar: they continue to appear for
> > a brief time in their old positions even after
> > the frame itself has been enlarged - and then
> > they jump out to where they belong (respecting
> > the new frame size).
> 
> Is this with or without double-buffering?

It's with inhibit-double-buffering set to t.
Whether or not that completely disables the
effect of the code that added double-buffering
I can't tell you.  If it does, then some other
changed than double-buffering support caused
the regression.

> If without, then it is not
> related to double-buffering, and should be
> reported separately.

Why should it be reported separately?  This bug
wasn't reported against double-buffering.  It's
about a new, Emacs 29, behavior that introduces
(in my setup at least) "Transient frame problems
on MS Windows".

The background being temporarily all black in
between the original frame size and the expanded
size is fixed by setting inhibit-double-buffering
to t.  But the temporary display of the scroll
bar and frame edge of the former-size frame,
inside the newly enlarged frame, is part and
parcel of what the bug describes: the former
frame is still shown, temporarily, inside the
expanded frame.

It doesn't matter how the frame is enlarged -
by code, by key, or by mouse dragging.  The bug
manifests in all cases.

The initial description of the bug did mention
the all-black portion of the newly expanded part,
but the fact of the original frame still being
displayed was also part of the description of
the problem.

Please don't confuse the bug/problem description
with Po Lu's guess of the problem being caused
by double-buffering and his suggestion that it
might go away by inhibiting double-buffering.

> AFAIU, the display code used when double-buffering is disabled was not
> changed in any way that would explain these phenomena.  If you have
> older Emacs binaries, I suggest to compare what they do on the same
> system with what Emacs 29.1 does when double-buffering is disabled.

As I mentioned, I am comparing.  I use older
Emacs releases every day.  I don't use Emacs
29, but I installed it and tried it out, and
immediately fell onto the reported problem.

> > > We had enough user experience before we decided to
> > > have this on by default.
> >
> > OK, good.  So now there's one user reporting
> > a new problem when trying to get back to no
> > double-buffering.  I'm sorry I don't have a
> > reproduction recipe.  Maybe another user will
> > be bit by the same problem and have better
> > info about it.
> 
> Even if you cannot show a reproducible "emacs -Q" recipe, it might
> help to see a clear step by step recipe with your configuration, which
> does reproduce the problem for you.

I know it would, but such a recipe is impractical
for me, and as I said, I'm sorry but it won't be
forthcoming.  I'm hoping (unfortunately) that I
may not be the only user to notice such behavior.
It wouldn't be the first time that has happened.