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

From: Drew Adams <[email-masked]>
Date: Fri, 29 Sep 2023 18:21:16 +0000

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

OK, thanks; good (for them, at least), and
good to know.

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

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

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.