From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Akira Kyle Newsgroups: gmane.emacs.devel Subject: Re: Motif support Date: Mon, 20 Dec 2021 14:07:06 -0700 Message-ID: References: <878rwhbb91.fsf.ref@yahoo.com> <878rwhbb91.fsf@yahoo.com> <83ee699irm.fsf@gnu.org> <87r1a99icp.fsf@yahoo.com> <835yrl9gob.fsf@gnu.org> <87fsqp9cvn.fsf@yahoo.com> <87mtkwzxpd.fsf@telefonica.net> <871r2898rl.fsf@yahoo.com> <87ilvkzx1m.fsf@telefonica.net> <87wnk07tfq.fsf@yahoo.com> <87sfuo7t0a.fsf@yahoo.com> <87czlszvcu.fsf@telefonica.net> <87h7b47rie.fsf@yahoo.com> <878rwgztoc.fsf@telefonica.net> <83ilvk9292.fsf@gnu.org> <8735mozno8.fsf@telefonica.net> <8335mo8wan.fsf@gnu.org> <87tuf43r5i.fsf@yahoo.com> <83wnjz1al2.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19200"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Po Lu , =?UTF-8?Q?=C3=93scar_Fuentes?= , Emacs developers To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 20 22:19:33 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mzQ4D-0004mP-Ex for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Dec 2021 22:19:33 +0100 Original-Received: from localhost ([::1]:42790 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mzQ4B-0006M1-Tg for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Dec 2021 16:19:32 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:53224) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mzPsS-0003Hw-GL for emacs-devel@gnu.org; Mon, 20 Dec 2021 16:07:24 -0500 Original-Received: from mail-lf1-f48.google.com ([209.85.167.48]:38474) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mzPsQ-00068T-Jj; Mon, 20 Dec 2021 16:07:24 -0500 Original-Received: by mail-lf1-f48.google.com with SMTP id x21so16330430lfa.5; Mon, 20 Dec 2021 13:07:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EY/h5dVfQP5KoWKZoIqXzEcFgbLBq39+fUOz+GdDMh4=; b=IVlUZAFMbKoJtjVj42KI+WmV3yWyZcB423sULWtuCVu2Tg3ANiYUogwLFAZd+Ny6b8 TofxlgIlmKBt/FKXfIKqNLS/qQ9j22cawjVXeFdAhikPDMfZIwEJxMp+za5iiLmq2pEn NljC5vDzC3oFkGoSM6jqqZ+seobH+I8ujktOrvVcydwALOpG1CHg4NwDao1AmPD5+DzZ ik7tAIGAo6Yz1Zq4aDQ4nf6p3aQLprNDBU9KUT366aaHy6XblKc/E5bCuS+6Go+/FjMU 2WiC9t3vC/xFOvMNGV3hNydo52aLUsT3itHFDp21eZIsLGA5tTZrXAxY1yDlsa14ieBn aHqA== X-Gm-Message-State: AOAM533ybngU3OXGM/lRWUyuRojWi3yTj24cdTbs4xXAais73oKuvqr/ ve7TfDQZQGl//w1/dTjQdnHTnjK55dwa89nD X-Google-Smtp-Source: ABdhPJyzSiXggkE3A25MVjGBUAPdQ0NuMmp5fGc3o34utcwX1py/vf7YYte5PLL4Fr7MhTBVws6JMg== X-Received: by 2002:a05:6512:130d:: with SMTP id x13mr17397431lfu.466.1640034440258; Mon, 20 Dec 2021 13:07:20 -0800 (PST) Original-Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com. [209.85.208.181]) by smtp.gmail.com with ESMTPSA id p17sm2598592ljm.138.2021.12.20.13.07.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Dec 2021 13:07:20 -0800 (PST) Original-Received: by mail-lj1-f181.google.com with SMTP id z8so18002657ljz.9; Mon, 20 Dec 2021 13:07:19 -0800 (PST) X-Received: by 2002:a2e:a28e:: with SMTP id k14mr16012133lja.488.1640034439130; Mon, 20 Dec 2021 13:07:19 -0800 (PST) In-Reply-To: <83wnjz1al2.fsf@gnu.org> X-Gmail-Original-Message-ID: Received-SPF: pass client-ip=209.85.167.48; envelope-from=aikokyle@gmail.com; helo=mail-lf1-f48.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:282541 Archived-At: On Mon, Dec 20, 2021 at 9:54 AM Eli Zaretskii wrote: > > I do know how the display code works and how it evolved, but frankly I > don't understand what you are trying to say, concretely. I understand > the vague thoughts and ideas of the technological advances in GUI vs > the development of the Emacs display, but do you actually have > something specific to suggest about that, like what could the Emacs > display engine do differently using some of these technologies? > because I think we all understand the general issues; it's specific > practical ideas that are missing, if we really want to modernize the > Emacs display code. > Sorry I don't have much to offer besides vague thoughts as I'm not an expert in emacs' display code nor computer graphics in general, I was more hoping it might prompt those who are experts to comment. Perhaps the answer is, as Stefan suggested, that the largest slowness in emacs' display is due to elisp, which has inherent difficulties in being parallelized. I think, though, that it's probably best to profile emacs' display to really understand what the bottlenecks are before thinking about how things could be done more efficiently, and often there are different approaches to parallelizing code that one cannot a priori decide which will be the optimal. My cursory understanding of the servo project is that they would often implemented several different parallel approaches to see which ones worked best in practice. > And even if you are talking about a complete redesign of the display > engine, then again, to make that even marginally practical, please > present specific ideas of such a redesign. That at least could give > someone motivation to sit down and develop those ideas at some point. I think the complexity of the current display code is a huge barrier to this type of experimentation and I wonder if there would be a cleaner abstraction for the various toolkits emacs can use than the current "redisplay_interface" struct which if I understand correctly, is the main way emacs currently abstracts each toolkit. > > Sure, but the question isn't a binary one (hardware accelerated vs > > not) but how well is the available hardware being utilized which is a > > much more difficult question to answer. > > The question that interests me is which part(s) of the Emacs display > code you'd like to accelerate using this hardware.