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

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

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

Thank you very much!  That helps.

I see mention of this in NEWS, now.  And I see
it described in (elisp) `Management Parameters'.

However, the positive reason that the default
behavior was changed is not really developed.
Both NEWS and the Elisp manual just say that
the default behavior (double buffering) aims
"to reduce display flicker".  Can you (and the
doc) please say more?

And this language in the manual is, I think,
unfortunate: if you "pine for that retro,
flicker-y feeling" then set the parameter to t.

Has anyone ever really reported any such flicker
on MS Windows?  I've never noticed any "display
flicker" there.  Quite the opposite.  I used
Emacs on Unix decades ago, and on GNU/Linux a
decade ago, and compared to that the display of
frames on Windows has always seemed far smoother
- and quicker.  I've read GNU/Linux users gripe
about how long it takes to create an Emacs frame,
for example, but I've never seen that complaint
from Windows users.

But maybe I don't know what's meant by that
vague term, i.e., just what to look for.  I have
multiple Emacs releases, so I can easily compare
- I'd like to know what to look for, to see
something possibly positive about the new default
behavior.
____

Also, the problem I described disappears for the
most part  - the transient black background, for
example.  But half of the problem remains.

The frame still transiently/briefly retains its
previous size, as seen clearly by the scroll bar
staying where it was for seconds - then finally
jumping out to the frame edge where it belongs
(e.g., in a single-window frame).

IOW, the frame does not appear altogether, at
once, in its new shape.  And I think it doesn't
get to the new shape as quickly as in older
releases.  Perhaps there's still some remnant
double-buffering behavior?

Maybe the new implementation for some reason
doesn't allow for the same performance and
integral (everything-at-once) behavior as the
old implementation?

IOW, the new default behavior is apparently _not_
completely removed by setting frame parameter
`inhibit-double-buffering' to t.  Dunno whether
anyone can easily reproduce/notice this annoyance,
but if so then maybe this bug can/should be kept
open till that's fixed.

Maybe there was some small oversight in the
implementation of the change, so that, e.g., the
background is handled more or less OK (as it was
in previous releases) but the scroll bar or frame
edge is not yet handled correctly.

And in any case I suggest that the benefits of
double buffering be documented better.  So far,
I haven't seen them.  To me, previous releases on
MS Windows are superior wrt frame display.