bug#32334: Window resize fails in remote X11

[Po Lu]

Robert Pluim <rpluim@gmail.com> writes:

> - Either no other program on the internet uses XDBE, or if they do
>   their users never use X11 forwarding over ssh
> - The emacs toolkit type doesnʼt matter, they all have visual problems
>   of one kind or another
> - XDBE calls are definitely being made, and they're not returning
>   errors
> - Itʼs not a timing issue: if I delay the XDBE setup until after the
>   initial frame has been set up and shown, then visual problems still
>   start occuring immediately after the XDBE initialization
>
> I also tested with Cygwin's XServer, which supports the double
> buffering extension. I used the same ssh session, and emacs came up
> and looked and worked fine.
>
> So at this point itʼs looking more like an issue with VcXsrv than with
> emacs. Iʼll see if I can engage with them after I get back from vacation.

Emacs is the only living program that still uses the double buffer
extension.  It is considered an obsolete but supported extension by the
X.Org developers, and not much priority is given to it by other X server
developers, aside from ensuring that the code to support it still
builds.

The recommended alternative is to create a pixmap and to use that as a
back buffer instead.  It will completely mess up color allocation on
some other X servers, and might lead to sub-optimial memory usage, so
replacing the Xdbe code with that entirely is not an option.

Instead, we could use the pixmap strategy on X servers that are known to
be buggy.  Off the back of my head I can list Hummingbird's X servers
(`x-server-vendor' usually returns "Hummingbird Ltd." or some variant
thereof), VcXsrv (which unfortunately cannot be easily identified) and
some versions of Xming (which identifies itself as X.Org, not much help
there either.)

The easy solution would to simply disable double buffering on those
servers, at the cost of some extra flickering to their users.