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

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

[Drew Adams]

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

In GNU Emacs 29.1 (build 2, x86_64-w64-mingw32) of 2023-08-02 built on
 AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.19045
System Description: Microsoft Windows 10 Pro (v10.0.2009.19045.3448)

Configured using:
 'configure --with-modules --without-dbus --with-native-compilation=aot
 --without-compress-install --with-tree-sitter CFLAGS=-O2'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB

(NATIVE_COMP present but libgccjit not available)

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252

Major mode: Messages

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny rfc822
mml mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util
text-property-search time-date subr-x mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils dired-aux cl-loaddefs
cl-lib dired dired-loaddefs rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads
w32notify w32 lcms2 multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 42193 5558)
 (symbols 48 5570 0)
 (strings 32 15949 1566)
 (string-bytes 1 430192)
 (vectors 16 11529)
 (vector-slots 8 226238 11868)
 (floats 8 40 25)
 (intervals 56 235 2)
 (buffers 984 10))

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]

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.

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

[Drew Adams]

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

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]

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

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

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

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

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.

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

[Eli Zaretskii]

> Cc: "66247@debbugs.gnu.org" <66247@debbugs.gnu.org>
> From: Drew Adams <drew.adams@oracle.com>
> 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.

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

[Drew Adams]

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

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

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "luangruo@yahoo.com" <luangruo@yahoo.com>,
>         "66247@debbugs.gnu.org"
> 	<66247@debbugs.gnu.org>
> Date: Fri, 29 Sep 2023 18:21:16 +0000
> 
> > 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).

Is this with or without double-buffering?  If without, then it is not
related to double-buffering, and should be reported separately.
AFAIU, the display code used when double-buffering is disabled was not
changed in any way that would explain these phenomena.  If you have
older Emacs binaries, I suggest to compare what they do on the same
system with what Emacs 29.1 does when double-buffering is disabled.

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

Even if you cannot show a reproducible "emacs -Q" recipe, it might
help to see a clear step by step recipe with your configuration, which
does reproduce the problem for you.

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

[Drew Adams]

> > > 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).
> 
> Is this with or without double-buffering?

It's with inhibit-double-buffering set to t.
Whether or not that completely disables the
effect of the code that added double-buffering
I can't tell you.  If it does, then some other
changed than double-buffering support caused
the regression.

> If without, then it is not
> related to double-buffering, and should be
> reported separately.

Why should it be reported separately?  This bug
wasn't reported against double-buffering.  It's
about a new, Emacs 29, behavior that introduces
(in my setup at least) "Transient frame problems
on MS Windows".

The background being temporarily all black in
between the original frame size and the expanded
size is fixed by setting inhibit-double-buffering
to t.  But the temporary display of the scroll
bar and frame edge of the former-size frame,
inside the newly enlarged frame, is part and
parcel of what the bug describes: the former
frame is still shown, temporarily, inside the
expanded frame.

It doesn't matter how the frame is enlarged -
by code, by key, or by mouse dragging.  The bug
manifests in all cases.

The initial description of the bug did mention
the all-black portion of the newly expanded part,
but the fact of the original frame still being
displayed was also part of the description of
the problem.

Please don't confuse the bug/problem description
with Po Lu's guess of the problem being caused
by double-buffering and his suggestion that it
might go away by inhibiting double-buffering.

> AFAIU, the display code used when double-buffering is disabled was not
> changed in any way that would explain these phenomena.  If you have
> older Emacs binaries, I suggest to compare what they do on the same
> system with what Emacs 29.1 does when double-buffering is disabled.

As I mentioned, I am comparing.  I use older
Emacs releases every day.  I don't use Emacs
29, but I installed it and tried it out, and
immediately fell onto the reported problem.

> > > 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.
> 
> Even if you cannot show a reproducible "emacs -Q" recipe, it might
> help to see a clear step by step recipe with your configuration, which
> does reproduce the problem for you.

I know it would, but such a recipe is impractical
for me, and as I said, I'm sorry but it won't be
forthcoming.  I'm hoping (unfortunately) that I
may not be the only user to notice such behavior.
It wouldn't be the first time that has happened.

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

[Eli Zaretskii]

tags 66247 moreinfo unreproducible
thanks

> From: Drew Adams <drew.adams@oracle.com>
> CC: "luangruo@yahoo.com" <luangruo@yahoo.com>,
>         "66247@debbugs.gnu.org"
> 	<66247@debbugs.gnu.org>
> Date: Sat, 30 Sep 2023 15:22:30 +0000
> 
> Please don't confuse the bug/problem description
> with Po Lu's guess of the problem being caused
> by double-buffering and his suggestion that it
> might go away by inhibiting double-buffering.

It was my guess as well, Po Lu just beat me up to posting it.

> > Even if you cannot show a reproducible "emacs -Q" recipe, it might
> > help to see a clear step by step recipe with your configuration, which
> > does reproduce the problem for you.
> 
> I know it would, but such a recipe is impractical
> for me, and as I said, I'm sorry but it won't be
> forthcoming.

Too bad.  Then this bug is unlikely to make any progress any time
soon.

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

[Drew Adams]

In addition to the problems described, even when
parameter `inhibit-double-buffering' is `t':

When applying a set of frame position and size
modifications, the transient appearance shows
not only the scroll bar in the initial position
but the overall frame, even after it's resized,
remains in the original position.  The final
position and location of the scroll bar are not
realized at the same time as the frame is resized.

There is a _general_ regression wrt the behavior
in all previous Emacs releases (back through 20,
at least).  Setting `inhibit-double-buffering' to
`t' removes only some of the problems introduced.

You may say that the rest of the frame-display
implementation, besides the addition of double
buffering, wasn't changed for Emacs 29, but that
doesn't seem to be the case.  Something has led
to a regression wrt frame display - multiple
frame parameters.

When a set of parameters are changed with one
`modify-frame-parameters' the effect is not to
change them all at once - and that's new (a
regression).  The frame is resized, and some
time later the other frame modifications take
effect.

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

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "luangruo@yahoo.com" <luangruo@yahoo.com>,
>         "66247@debbugs.gnu.org"
> 	<66247@debbugs.gnu.org>
> Date: Mon, 9 Oct 2023 18:33:48 +0000
> 
> In addition to the problems described, even when
> parameter `inhibit-double-buffering' is `t':
> 
> When applying a set of frame position and size
> modifications, the transient appearance shows
> not only the scroll bar in the initial position
> but the overall frame, even after it's resized,
> remains in the original position.  The final
> position and location of the scroll bar are not
> realized at the same time as the frame is resized.
> 
> There is a _general_ regression wrt the behavior
> in all previous Emacs releases (back through 20,
> at least).  Setting `inhibit-double-buffering' to
> `t' removes only some of the problems introduced.
> 
> You may say that the rest of the frame-display
> implementation, besides the addition of double
> buffering, wasn't changed for Emacs 29, but that
> doesn't seem to be the case.  Something has led
> to a regression wrt frame display - multiple
> frame parameters.

Needless to say, I see none of this on my system.  But since you
didn't post any information regarding how to reproduce this, not even
which commands and/or functions are used when this happens, it is hard
to tell whether it simply doesn't happen here or you do something that
I don't.

> When a set of parameters are changed with one
> `modify-frame-parameters' the effect is not to
> change them all at once - and that's new (a
> regression).  The frame is resized, and some
> time later the other frame modifications take
> effect.

Frame parameters were always applied one by one in Emacs, not
together.  This is not a regression, this is how Emacs always worked.

Bottom line: I find such "bug reports" extremely frustrating, because
nothing, literally nothing, can be done about them without extra
details.

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

[Drew Adams]

> > In addition to the problems described, even when
> > parameter `inhibit-double-buffering' is `t':
> >
> > When applying a set of frame position and size
> > modifications, the transient appearance shows
> > not only the scroll bar in the initial position
> > but the overall frame, even after it's resized,
> > remains in the original position.  The final
> > position and location of the scroll bar are not
> > realized at the same time as the frame is resized.
> >
> > There is a _general_ regression wrt the behavior
> > in all previous Emacs releases (back through 20,
> > at least).  Setting `inhibit-double-buffering' to
> > `t' removes only some of the problems introduced.
> >
> > You may say that the rest of the frame-display
> > implementation, besides the addition of double
> > buffering, wasn't changed for Emacs 29, but that
> > doesn't seem to be the case.  Something has led
> > to a regression wrt frame display - multiple
> > frame parameters.
> 
> Needless to say, I see none of this on my system.  But since you
> didn't post any information regarding how to reproduce this, not even
> which commands and/or functions are used when this happens, it is hard
> to tell whether it simply doesn't happen here or you do something that
> I don't.
> 
> > When a set of parameters are changed with one
> > `modify-frame-parameters' the effect is not to
> > change them all at once - and that's new (a
> > regression).  The frame is resized, and some
> > time later the other frame modifications take
> > effect.
> 
> Frame parameters were always applied one by one in Emacs, not
> together.  This is not a regression, this is how Emacs always worked.
> 
> Bottom line: I find such "bug reports" extremely frustrating, because
> nothing, literally nothing, can be done about them without extra
> details.

Yes, as I said, I'm sorry I don't have the time
needed to dig into this in detail.

Here's a simple recipe from emacs -Q that should at
least enable you to see the lag in display of the
scroll bar.  It's not kept contiguous with the frame
edge as you move that edge out.

emacs -Q

M-x customize-option default-frame-alist

Add an entry for inhibit-double-buffering as t.

Set the option value for the current session.

`C-x 5 2' or in some other way get a new frame,
so `default-frame-alist' kicks in.

Grab the right frame edge with your mouse and
move it to the right.  I see a lag: the scroll
bar stays where it is briefly, then finally
catches up with the new position of the right
frame edge.

The inhibition of double buffering removes
the display of a black background between the
initial position (and lagging display) of the
scroll bar and the new position of the right
frame edge.  But it doesn't remove the lag
in positioning of the scroll bar adjacent to
the right frame edge.  There's still a
transient visible gap; it just no longer has
a black background.

The faster you move your mouse to the new
right-edge position the wider the gap.  IOW,
the correct redisplay seems to occur after
the same time duration, so the greater the
distance between the initial and final right
edge positions the wider the gap you see.

The bug report specifies the Emacs build I'm
using.  Dunno whether the problem is just with
that build.  If it is then maybe you won't see
the problem.

HTH.

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

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "luangruo@yahoo.com" <luangruo@yahoo.com>,
>         "66247@debbugs.gnu.org"
> 	<66247@debbugs.gnu.org>
> Date: Mon, 9 Oct 2023 19:49:14 +0000
> 
> emacs -Q
> 
> M-x customize-option default-frame-alist
> 
> Add an entry for inhibit-double-buffering as t.
> 
> Set the option value for the current session.
> 
> `C-x 5 2' or in some other way get a new frame,
> so `default-frame-alist' kicks in.
> 
> Grab the right frame edge with your mouse and
> move it to the right.  I see a lag: the scroll
> bar stays where it is briefly, then finally
> catches up with the new position of the right
> frame edge.

I see the same in Emacs 28, so this isn't a regression in Emacs 29.
When Emacs needs to redraw the frame, it actually asks the MS-Windows
GUI subsystem to do that, and the update takes time (and happens in a
separate UI thread).  So these small lags are expected.

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

[Drew Adams]

> I see the same in Emacs 28, so this isn't a regression in Emacs 29.
> When Emacs needs to redraw the frame, it actually asks the MS-Windows
> GUI subsystem to do that, and the update takes time (and happens in a
> separate UI thread).  So these small lags are expected.

You're right about that.  So that simple recipe
isn't good enough.

I'm guessing that you're also right about the
only problem being the double-buffering.  I'm
guessing that for some reason things are just
somewhat slower in Emacs 29 for frame display,
so I notice the lingering scroll-bar position
more.

I think you can close this bug, the general
solution being to add (inhibit-double-buffering . t)
to `default-frame-alist'.
___

BTW, what's the rationale behind making this
a frame parameter rather than just an option
that affects all frames?  Presumably there is
some use case for having it ON or OFF for only
specific frames or groups of frames.  I'm
curious what such a use case might be.

Because of this choice, I need to customize
both `default-frame-alist' and
`special-display-frame-alist'.  (I know that
Emacs considers that option to be obsolete,
but it's very important to me.)  There are
other frame-display alists, as well, and
users might have still other alists governing
different groups/types of frames.

Again, I imagine there's a use case for this
frame parameter to be a frame parameter, as
opposed to just an option that affects all
frames, but so far, I can't imagine what such
a use case might be.

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

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "luangruo@yahoo.com" <luangruo@yahoo.com>,
>         "66247@debbugs.gnu.org"
> 	<66247@debbugs.gnu.org>
> Date: Tue, 10 Oct 2023 15:13:19 +0000
> 
> BTW, what's the rationale behind making this
> a frame parameter rather than just an option
> that affects all frames?  Presumably there is
> some use case for having it ON or OFF for only
> specific frames or groups of frames.  I'm
> curious what such a use case might be.

This comes from Unix, where each frame can be on a different X
display, and therefore could use a different display driver.

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

[Drew Adams]

> > BTW, what's the rationale behind making this
> > a frame parameter rather than just an option
> > that affects all frames?  Presumably there is
> > some use case for having it ON or OFF for only
> > specific frames or groups of frames.  I'm
> > curious what such a use case might be.
> 
> This comes from Unix, where each frame can be on a different X
> display, and therefore could use a different display driver.

Aha!  Now it makes sense to me (it's been a long
time since I used X Window).

I wonder whether it might make sense for the doc
to say something about this?

Maybe more importantly I wonder whether it might
make sense to add a user option that has the
effect of turning on/off double-buffering for
all frames.

If that were done, there'd be two possibilities
for how to handle the combination of that option
with the frame parameter:

1. The option value always overrides the frame
parameter.

2. The frame parameter always overrides the option.

Maybe #2 makes more sense.  Alternatively, the
option could have more values than just on/off:

. ON, and option overrides frame parameter
. OFF, and option overrides frame parameter
. ON, and frame parameter overrides option
. OFF, and frame parameter overrides option

Do you think it would be good to add an option?

If so, maybe its default value should depend
on the `system-type'?  E.g., for `windows-nt'
it could default to ON, with option overriding
frame parameter, and for other `system-type's
it could default to ON, with frame parameter
overriding option.

I know you think that even for most MS Windows
users the default value should be ON.  The
point of having an option would be to simplify
turning the behavior on/off.  If the use case
for using the frame parameter is limited to
what you described, then maybe most users
(even on UNIX-like platforms) would appreciate
a simple option.

Anyway, this is OT for this bug, which can be
closed, IMO.

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

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "luangruo@yahoo.com" <luangruo@yahoo.com>,
>         "66247@debbugs.gnu.org"
> 	<66247@debbugs.gnu.org>
> Date: Tue, 10 Oct 2023 15:53:56 +0000
> 
> > > BTW, what's the rationale behind making this
> > > a frame parameter rather than just an option
> > > that affects all frames?  Presumably there is
> > > some use case for having it ON or OFF for only
> > > specific frames or groups of frames.  I'm
> > > curious what such a use case might be.
> > 
> > This comes from Unix, where each frame can be on a different X
> > display, and therefore could use a different display driver.
> 
> Aha!  Now it makes sense to me (it's been a long
> time since I used X Window).
> 
> I wonder whether it might make sense for the doc
> to say something about this?
> 
> Maybe more importantly I wonder whether it might
> make sense to add a user option that has the
> effect of turning on/off double-buffering for
> all frames.

We already have that, for every frame-parameter: customize both
initial-frame-alist and default-frame-alist.  Why do we need something
else, and why should this particular parameter be different from all
the other frame parameters?

> Do you think it would be good to add an option?

No, I think it would be a needless complication.

> Anyway, this is OT for this bug, which can be
> closed, IMO.

Done.

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

[Drew Adams]

> > I wonder whether it might make sense for the doc
> > to say something about this?

?

> > Maybe more importantly I wonder whether it might
> > make sense to add a user option that has the
> > effect of turning on/off double-buffering for
> > all frames.
> 
> We already have that, for every frame-parameter: customize both
> initial-frame-alist and default-frame-alist.  Why do we need something
> else, and why should this particular parameter be different from all
> the other frame parameters?

There are several more `*-frame-alist' variables
than those two.  `M-x apropos frame-alist'.
And user code can create still more.