PGTK-related misconceptions

[Po Lu]

Morgan Smith <morgan.j.smith@outlook.com> writes:

> I'd like to report that my super key stopped registering.  I suspected
> commit 1404e16975 caused it so I did a quick `git revert 1404e16975`
> ontop of 807682de1e and that fixed it.

Crystal ball says you are using X Windows, and have to put

  remove mod4 = Hyper_L

in your ~/.Xmodmap file, because GTK doesn't try as hard as regular X11
Emacs to work around the common kind of virtual modifier
misconfiguration.

People using X should _never_ use PGTK.  The regular X build does a much
better job at supporting that than PGTK ever will.

It is completely pointless to put up with half-working child frames,
random keyboard-related lossage, random frame placement/resizing
failures, so the actual fix is to delete `--with-pgtk' from your calls
to configure.

Similarly, people building packages with PGTK enabled that are labeled
"enhanced" are doing their users a disservice.  No packager should
enable PGTK by default, and every package should ideally come with a big
disclaimer warning against using PGTK on window systems otherwise
supported by Emacs, since time and experience shows that Emacs generally
does a much better job at their support than GTK.

Many people are also being mislead by articles on the internet claiming
that PGTK leads to faster redisplay, such as this one:
http://www.cesarolea.com/posts/emacs-native-compile

That is not true, since regular Emacs with cairo uses more-or-less the
same rendering path as PGTK, except when PGTK runs on Wayland, where it
uses software rendering and does image compositing in software, and is
thus slower than everything else.  Scrolling on PGTK is also not as
efficient as XCopyArea requests.

But the difference in speed even on Wayland is negligible, not easy to
benchmark, and not at all visible to the human eye.