unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Dirk-Jan C. Binnema" <djcb.bulk@gmail.com>
To: emacs-devel@gnu.org
Subject: Re: PGTK-related misconceptions
Date: Tue, 19 Apr 2022 12:10:09 +0300	[thread overview]
Message-ID: <877d7lmmz9.fsf@gmail.com> (raw)
In-Reply-To: <87lew7qdtj.fsf@yahoo.com>


On Friday Apr 15 2022, Po Lu wrote:

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

Appreciate the efforts on this, but the outcome seems somewhat
unsatisfactory, if I understand correctly:

- we have the "non-pure" gtk build which supports X (although gtk has a
  wayland backend, non-pure gtk assumes X)
- we have "pure" gtk, which supports X and Wayland, but now it turns
  out there's a bunch of limitations on X.

From the the time before pgtk got merged, I can't remember any wide
discussion of it being wayland-only. Perhaps I misremember.

I regularly use both X and Wayland, and having to have two emacsen (and
remember to use the right one) just for that seems sub-optimal. Wouldn't
it be better to have a single gtk3 backend? For users and developers and
distributors?

But maybe the problems is small, i.e. perhaps pgtk works fine on X, but
doesn't currently implement a handful of things, which we can document?
Then users can decide if they can live with that.

Kind regards,
Dirk.

-- 
Dirk-Jan C. Binnema                  Helsinki, Finland
e:djcb@djcbsoftware.nl                                
gpg: 6987 9CED 1745 9375 0F14 DA98 11DD FEA9 DCC4 A036



  parent reply	other threads:[~2022-04-19  9:10 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <DM5PR03MB3163BBCF9626AD3B88900011C5EE9@DM5PR03MB3163.namprd03.prod.outlook.com>
2022-04-15  2:29 ` PGTK-related misconceptions Po Lu
2022-04-15  7:11   ` Byung-Hee HWANG
2022-04-15 16:24   ` Eric Abrahamsen
2022-04-18  5:18   ` Sean Whitton
2022-04-18  5:31     ` Po Lu
2022-04-18  5:43       ` Sean Whitton
2022-04-18  5:57         ` Po Lu
2022-04-18 18:27           ` Sean Whitton
2022-04-18 19:49           ` Jim Porter
2022-04-19  1:02             ` Po Lu
2022-04-19  2:46               ` Sean Whitton
2022-04-19  2:18             ` Tim Cross
2022-04-19  5:56               ` Eli Zaretskii
2022-04-19  8:13                 ` Tim Cross
2022-04-19 10:32                   ` Eli Zaretskii
2022-04-19  9:10   ` Dirk-Jan C. Binnema [this message]
2022-04-19 10:42     ` Po Lu
2022-04-19 11:53     ` Phil Sainty
2022-04-19 13:58       ` Sean Whitton
2022-04-20  3:29         ` Phil Sainty
2022-04-20  4:48           ` Stefan Monnier
2022-04-19 16:51       ` Yuri Khan
2022-04-22  5:44         ` Pankaj Jangid
2022-04-18 21:50 Trey
2022-04-19  0:59 ` Po Lu
2022-04-19  3:28   ` Trey Peacock
2022-04-19  4:27     ` Po Lu
2022-04-19 23:02       ` Trey Peacock
2022-04-20  0:48         ` Po Lu
2022-04-20  2:33           ` Trey Peacock
2022-04-20  4:05             ` Po Lu
2022-07-25 21:18     ` Akira Kyle
2022-07-26  2:08       ` Po Lu
2022-07-26 12:10         ` Lars Ingebrigtsen
2022-07-26 12:35           ` Po Lu
2022-07-29 14:26             ` Stefan Monnier
2022-07-30  0:58               ` Po Lu
2022-07-26 21:36         ` Akira Kyle
2022-07-27  2:48           ` Po Lu
2022-07-27  8:34             ` Trey Peacock
2022-07-27  9:10               ` Po Lu
2022-07-27 13:45                 ` Trey Peacock
2022-07-27 13:52                   ` Po Lu
2022-07-28  1:39             ` Akira Kyle
2022-07-28  2:50               ` Po Lu
  -- strict thread matches above, loose matches on Subject: below --
2022-04-20  7:52 Trey Peacock
2022-04-20  8:25 ` Po Lu
2022-04-20 13:13   ` Brian Cully

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877d7lmmz9.fsf@gmail.com \
    --to=djcb.bulk@gmail.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).