Subject: Re: [External] : Re: bug#66247: 29.1; Transient frame problems with Emacs 29 on MS Windows

From: Eli Zaretskii <[email-masked]>
Date: Sat, 30 Sep 2023 16:42:33 +0300

> From: Drew Adams <[email-masked]>
> CC: "[email-masked]" <[email-masked]>,
>         "[email-masked]"
> 	<[email-masked]>
> Date: Fri, 29 Sep 2023 18:21:16 +0000
> 
> > 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?  If without, then it is not
related to double-buffering, and should be reported separately.
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.

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