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

From: Eli Zaretskii <[email-masked]>
Date: Fri, 29 Sep 2023 19:32:11 +0300

> Cc: "[email-masked]" <[email-masked]>
> From: Drew Adams <[email-masked]>
> Date: Fri, 29 Sep 2023 16:17:34 +0000
> 
> > > 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,

Which is the truth.

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

Almost all of them.  You are a happy exception.

But flickering is only seen when doing certain operations, s oI guess
you don't do them, or don't pay attention to the flicker.

> 1. Why change the _default_ behavior?

Because the default on X was changed in the same way.

> 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)?

It is like that here.

> For me, this change is a fairly big regression.

It is expected that it will cause a regression on some systems, which
is why the way to disable double-buffering is in NEWS.

> Changing default behavior shouldn't, in general,
> happen willy-nilly with a new release.

It didn't.  We introduced it in Emacs 26 (but not on Windows).

> It's generally better to wait for user experience and request - even
> a long time - before changing the _default_ behavior.

We had enough user experience before we decided to have this on by
default.