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

[Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Drew Adams <drew.adams@oracle.com> writes:

> Feel free to close this if it doesn't ring a bell or doesn't seem
> actionable.  I likely won't be able to provide any more information, so
> this is pretty much a "HTH".  I'm hoping I'm not the only one seeing
> such problems.
>
> With my setup, which uses `default-frame-alist' etc., starting with
> Emacs 29 I notice a consistent annoyance each time I open a new frame or
> change the size of a frame - which I do very often.
>
> One change is that doing that seems to take longer; it used to be pretty
> much instantaneous (on MS Windows) to create and resize frames.
>
> But the annoyance isn't just that frame changes are slower.
>
> If I increase the size of a frame, for example (whether by program or
> dragging the edge with the mouse), What I see is that the frame size is
> changed pretty quickly, as before, but I see the old  display of the
> frame, undchanged, within the new frame boundary, and the rest of the
> frame (the new, additional space) is just black (or maybe sometimes
> white, e.g., when creating a frame?).  This is only momentary - just a
> second or two, but it happens each time and is quite annoying.
>
> I use my same setup everyday with Emacs versions from Emacs 20 through
> Emacs 28 without such a problem.  Something new must be going on in
> Emacs 29.
>
> I doubt it's related, but my Emacs 29.1.2 has this info (from a
> `runemacs -Q' session, though I'm sending this from a session that
> uses my setup):

Emacs 29.1 supports double buffering under MS-Windows, which incurs a
minor performance penalty on frame creation and resizing.  If you wish
to turn it off, you have but to insert:

  (inhibit-double-buffering . t)

within default-frame-alist.