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

[Drew Adams]

> > 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?
> 
> No, because the flicker manifests differently
> for each person who encounters it.

Sounds like a cop-out.  Especially if someone
hasn't seen any flicker before.

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

How about fixing it?  The doc gives the
impression that there's something wrong
with what was formerly the default behavior,
suggesting that if you now jump through the
added hoop to change that option value you're
somehow looking for trouble, instead of just
restoring (at least partially) NON-flickering.

> > Has anyone ever really reported any such flicker
> > on MS Windows?  I've never noticed any "display
> > flicker" there.  Quite the opposite.  I used
> 
> That's subject to the graphics driver installed, I believe.  Many MS
> Windows users reported severe flicker while scrolling in the past, a
> problem that has all but vanished with the introduction of double
> buffering.

Many MS Windows users?  Are you sure?  And
how many had no problem, and so never sent
a non-complaint because of no flickering,
let along no "severe" flickering?

IOW, what makes you think there was a big
problem that needed fixing, and especially
what makes you think that that "fix" should
be imposed as the new default behavior?

It might be subject to the graphics driver,
but FWIW, I've been using Emacs on Windows
since the 90s, which obviously means with
multiple different graphics drivers, and
until _now_ I've never had a problem with
frame modification and display.

I wouldn't have a problem with Emacs
offering double-buffering for MS Windows,
as an opt-in option.  But:

1. Why change the _default_ behavior?

2. Can you please fix the no-longer-default,
   longstanding-default behavior, so that frame 
   modification is as smooth and as quick as
   before (no jerky, delayed re-creation of some
   parts, such as frame edge/scroll-bars)?

For me, this change is a fairly big regression.
Not just no gain, but added pain.  Unnecessary
pain.

Changing default behavior shouldn't, in general,
happen willy-nilly with a new release.  It's
generally better to wait for user experience and
request - even a long time - before changing the
_default_ behavior.

Emacs dev used to be very respectful of that.
Don't "fix" default behavior, if it ain't broke.

You may be trying to make Emacs on MS Windows
seem more like Emacs on GNU/Linux, but that
shouldn't include making frame display worse.