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: Rethinking the design of xwidgets Date: Thu, 15 Oct 2020 10:25:11 -0600 Message-ID: <86362fbgns.fsf@akirakyle.com> References: <864kmzupp0.fsf@akirakyle.com> <835z7e2ouj.fsf@gnu.org> <86v9fet5sg.fsf@akirakyle.com> <83imbe1040.fsf@gnu.org> <86pn5luak4.fsf@akirakyle.com> <83362g27y6.fsf@gnu.org> <86mu0obpr7.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8724"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.4.13; emacs 28.0.50 Cc: Eli Zaretskii , Stefan Monnier , emacs-devel@gnu.org To: Arthur Miller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Oct 15 18:27:27 2020 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 1kT66B-00029M-LW for ged-emacs-devel@m.gmane-mx.org; Thu, 15 Oct 2020 18:27:27 +0200 Original-Received: from localhost ([::1]:56778 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kT66A-00042U-Le for ged-emacs-devel@m.gmane-mx.org; Thu, 15 Oct 2020 12:27:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38144) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kT645-0003Pu-CN for emacs-devel@gnu.org; Thu, 15 Oct 2020 12:25:17 -0400 Original-Received: from mail-il1-f195.google.com ([209.85.166.195]:43836) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kT643-0006Cu-Eb; Thu, 15 Oct 2020 12:25:17 -0400 Original-Received: by mail-il1-f195.google.com with SMTP id k1so4869783ilc.10; Thu, 15 Oct 2020 09:25:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version; bh=MyQlspaoB7NaP6bRcdgDSWeI3oS1YxnTjvMyckKp2Qs=; b=S8FgFwnShLGJ+VG71hgZHpHJNWIXCIm2Kyg1BLsi0KG1FhoBADPHD+UAeDQjZ1WVe5 YdnK6lSxA7yp1VX4n7EXmWb+JokwGD+/dSCFhc+zZXkdP8KOI/PaBRbfkn1Aa3hvaLzf yym+7QgNA/wNt62Rtl3eTdxTOSTbbgAnbgbpSAqGLt4UM42twJelGkMBEsfJG7jZ/FE7 0rceMykOjW71jWEbqsYiR2d3KAaVZBngVI240Y9XMyJnPpr/GE8f0E9g8sPYPaJHMmOk zuBIJKJkcgQ39cI9PnaeK4XHCqxoolFNeLWjyfZQJsKHmP8uPIdcJSuuT+1FBlxUlEe3 TSbw== X-Gm-Message-State: AOAM531Qw9Evtxlyh0DUKALbgrD2FDJCZQNeuID1zT2BxBzOIbc9JBGF dfcsyUev3kEI0kaQy+j9LNcN5SyzcKnfyw== X-Google-Smtp-Source: ABdhPJzn5Vaw5I/+a5B3XFidIPguWAnQeODymmUge2Vjv86JzsojiDkXjROafZ7oniimHb9mtFeogw== X-Received: by 2002:a05:6e02:664:: with SMTP id l4mr3923150ilt.81.1602779113282; Thu, 15 Oct 2020 09:25:13 -0700 (PDT) Original-Received: from lore ([2601:281:8080:45f0:9965:e519:2870:cde8]) by smtp.gmail.com with ESMTPSA id i7sm2935000ilq.64.2020.10.15.09.25.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Oct 2020 09:25:12 -0700 (PDT) In-reply-to: Received-SPF: pass client-ip=209.85.166.195; envelope-from=aikokyle@gmail.com; helo=mail-il1-f195.google.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/15 12:25:13 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] 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.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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.23 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:257748 Archived-At: On Thu, Oct 15, 2020 at 06:48 AM, Arthur Miller wrote: >> As someone who has done a little bit of GPU programming, I >> think Emacs should >> stay as far away from needing to care about the architecture >> and optimization >> for GPUs as possible. It is hard and very non-portable. > AFAIK OpenGL runs on more systems then Emacs, and is considered > as > probably THE easiest graphics API out there (Turtle graphics > probably > being easier :-)). > > It is superseeded by Vulkan, but Vulkan is probably too much for > an > application like Emacs in terms of complexity vs benefit. Just a disclaimer that I haven't actually worked with OpenGL, my gpu experience was centered to compute instead of graphics tasks, so take everything I say with that grain of salt. Just because OpenGL is very cross platform, doesn't means its the preferred graphics API on a given platform. Higher level graphics APIs will often target some subset of OpenGL, Vulcan, Metal, and Direct3D depending on what platforms they want to support and what gives them the best performance. I think Apple would love to kick opengl out of its ecosystem and force everyone to use Metal and AFAIK already has done so on iOS since they now control the physical GPU implementation with their own custom silicon. Furthermore, OpenGL being a low level graphics API, doesn't try to make decisions for you about the most efficient way to render what you have. Depending on the size and number of objects you want to draw and the resolution of the screen you want them draw on, some task will be better done on the CPU while others will be better served on a GPU. I don't think Emacs should be trying to figure that out since it can be difficult to do right and requires good performance benchmarking abilities. >> I should have clarified >> in my prior email that I really meant that Emacs could take >> advantage of newer >> hardware like GPUs and other SIMD vectorization units not >> directly because it is >> a huge PITA to work with, but through appropriate high level >> libraries. I don't >> think Emacs should be in the business of trying to actually >> draw primitives like >> lines and rectangles onto the glass directly whether through >> the frambuffer or >> low level gpu primitives like opengl. It requires specific >> expertise to get >> right and do efficiently that I think is beyond the scope of >> Emacs development. >> >> Since Emacs already has its own internal abstraction for >> actually doing the >> drawing through the redisplay_interface, my point was more that >> Emacs should >> gain hardware acceleration by ensuring the GUI toolkits it uses >> take advantage >> of such features. I think gtk 4 will have even more integration >> with hardware >> acceleration, > In my world, Emacs would be better shying away from big GUI > toolkits and > ginormous dependencies. > > Emacs window is (logically) one giant glorified tty in > principle; tucked > into an OS window and Emacs does it's own redisplay of the major > os > window area, so GUI toolkits are really just placeholders for > Emacs to > render. Buttons, menus, toolbars can all be implemented by Emacs > buffers > rendered as Frames, or Windows. Does not blend very well into > Gnome or > KDE world, but with some styling might be pretty too look at > anyway. > > As I udnerstand Emacs now does it's own > font and text rendering via Freetype , so question is if needs > Gtk at > all more then being pretty on Gnome desktops? Maybe Cairo alone > is not > bad, since it can be used as graphics API to render to and there > are > also hardware accelerated versions via opengl bindings (look in > Mesa source). My understanding of Emacs rendering is that it does rely on GUI toolkits more that you may think. I think the NS code renders via macOS's native font rendering, while on when on X --with-cairo, Emacs uses Freetype to render text. Perhaps someone may decide to implement text rendering using Pango to be more inline with the way GTK renders text. Since Emacs doesn't even handle drawing its own rectangles but rather lets each toolkit draw them it its own native way I'm not sure it makes sense to move Emacs towards doing even more low level graphics stuff then it already does. In principle I think one could implement a EGL redisplay_interface which would then run across platforms, however it would potentially be a lot more code to implement everything from such level drawing primitives than the using the toolkits and it would loose the "native look" that the current, higher level approach maintains. I think the mac people tend to think their native text rendering is superior so it might be a hard sell to try to move Emacs to a cross-platform "rendered in-house" model. I think it would be really neat to explore such rendering backends for Emacs, I'm just not sure how much it would simplify things or bring tangible speed improvements. The webrender backend that someone made in remacs is in this vein, although I think even webrender is a much higher level graphics API since it sits atop OpenGL. [1] https://github.com/remacs/remacs/pull/1581