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

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

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