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: Wed, 14 Oct 2020 12:07:38 -0600 Message-ID: <86pn5kbs0l.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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7993"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.4.13; emacs 28.0.50 Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 14 20:09:55 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 1kSlDm-0001yk-PU for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Oct 2020 20:09:54 +0200 Original-Received: from localhost ([::1]:51780 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kSlDl-0006ee-Oo for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Oct 2020 14:09:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55960) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kSlBh-00054q-B1 for emacs-devel@gnu.org; Wed, 14 Oct 2020 14:07:49 -0400 Original-Received: from mail-il1-f178.google.com ([209.85.166.178]:32809) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kSlBf-0000Ok-5h; Wed, 14 Oct 2020 14:07:44 -0400 Original-Received: by mail-il1-f178.google.com with SMTP id j8so331726ilk.0; Wed, 14 Oct 2020 11:07:42 -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:content-transfer-encoding; bh=ja/WzWDpSyFdNHs4vLVe5YVFwZ883Yy4AzgRZ8lh9xw=; b=WwjmSTPjwWiVdfaoxLCwy2j5HFxu1t2uMUjkcrlJjOa5v7t6REdueJnpsF7nMhKrpW 34OvqHgvZYHaIi29z4a1x1AxHRfAPcKFXpURCr4cDupTv6SVAFwZdjLjUJLYTTJsoPII A3o6PFVoFG6FE/MTpEaIrgGxVpKS4vckK0ENDKsYVN1+5uiwhuPgarz/jJVlVdKlGUkQ 2zmofXHeysSVKyDbUNeVThOoZwNLXL4r5ZPOEoWIdlVADBZdOA5v2/+XXfh1t+mi8TTJ brqbtLCZd8Ga7N8YDVY5P+Ze84s3IDtcYaAIKOgQRchNLYzet7tJYRPNOx5Z2ZueIh9V bChQ== X-Gm-Message-State: AOAM533jl3xe0/SkzN/KGGXPGeNMxEP/VEcFfcdntfuNQQmQzgllGcYA LOWehrMagk2fI0AfByz0jKuGAftEPgv7qrAQ X-Google-Smtp-Source: ABdhPJwtRuzEB9GCSGXOeyBmr3ljjjfUgQbI43YaTrAfZJzSlOJHJm6aQxT3HGc7i/6pJ6nYC95Cmg== X-Received: by 2002:a92:9ec7:: with SMTP id s68mr291022ilk.143.1602698860799; Wed, 14 Oct 2020 11:07:40 -0700 (PDT) Original-Received: from lore ([2601:281:8080:45f0:7f70:5415:b75f:2b9]) by smtp.gmail.com with ESMTPSA id i4sm100325ilc.27.2020.10.14.11.07.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Oct 2020 11:07:40 -0700 (PDT) In-reply-to: <83362g27y6.fsf@gnu.org> Received-SPF: pass client-ip=209.85.166.178; envelope-from=aikokyle@gmail.com; helo=mail-il1-f178.google.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/14 14:07:41 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.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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:257671 Archived-At: On Wed, Oct 14, 2020 at 08:33 AM, Eli Zaretskii =20 wrote: >> Can actions be triggered on a click and drag as one would do to=20 >> pan within a plot? > > I didn't have time to try that, but just looking at the code, I=20 > don't > see anything that makes the clocks on images special, so I'd=20 > expect > the same modifiers and drag-detection code to work. And if it > doesn't, I seed no reason why we couldn't teach it to do so. Good to know. >> As far as I know there are really only two FLOSS PDF libraries=20 >> out=20 >> there: poppler and muPDF. Between them poppler supports more=20 >> PDF=20 >> features and seems to be more widely used. I agree this isn't=20 >> really as compelling of a use case for xwidgets, but I seems=20 >> like=20 >> it would be easier to achieve better PDF rendering via=20 >> xwidgets. > > I can see how that is tempting: the image handling is taken care=20 > of. > What I'm saying is that this advantage should be carefully=20 > weighed > against the disadvantages and difficulties in integrating such > self-managing objects into the Emacs display code. OK. I'm still learning about the redisplay optimizations so=20 hopefully I'll have a better idea of what those disadvantages are=20 as I play with the existing way xwidgets works with redisplay. >> > E.g., the kludge in dispnew.c around line 4365. It disables=20 >> > one >> > of the most important redisplay optimizations in Emacs, once=20 >> > you >> > build with xwidgets enabled. >>=20 >> Ah, I had briefly looked at that but I wasn't sure how=20 >> important=20 >> it was. I may be able to make some progress on that but it's=20 >> hard=20 >> to understand the context for that function. It seems like that=20 >> function is responsible for an optimization that avoids=20 >> redrawing=20 >> glyphs if the window is being scrolled by copying them > > Not only if the window is scrolled, but also if the previous=20 > display > can be converted into the current display by scrolling some of=20 > the > stuff that is already on the glass. the algorithm is a basic > comparison of the current and desired display, similar to what=20 > the > Diff utility does. > >> however I couldn't find where or how the glyphs are actually=20 >> copied? > > See the calls to rif->scroll_run_hook. Thanks, this helps! >> I'm just starting to dig my teeth into some of that. However=20 >> I'm=20 >> wondering if anyone has more recently tried to quantify the=20 >> improvements the various redisplay optimizations make to both=20 >> actual and perceived render time of Emacs. For example the=20 >> comment=20 >> on the scrolling_window function in dispnew.c that you pointed=20 >> me=20 >> too references that it is implementing an algorithm from 1978,=20 >> perhaps it would be worth exploring if there are any=20 >> algorithmic=20 >> advances? > > I don't think that algorithm is less optimal nowadays than it=20 > was back > then; the really interesting question is how much it saves us=20 > when > compared to simply redisplaying all those lines. Yes that is the better question to ask first. >> It strikes me that perhaps some optimizations may no longer be=20 >> as >> necessary on modern hardware or on GUI displays as they were=20 >> when >> running emacs in a VT on 20 year hardware. > > Those are very good questions. I'm not aware of any such > investigations since the current redisplay optimizations were > implemented around 20 years ago: at that time, Gerd M=C3=B6llmann,=20 > who > developed the current display engine, did add optimizations one=20 > by one > until he got reasonable redisplay performance. > > Measuring the speedups from each of the several optimizations is=20 > an > important job, but it's a large job. For starters, one needs to=20 > come > up with a large enough and representative enough sample of=20 > redisplay > use cases, and that is not easy. So I'd encourage you (or=20 > anyone > else, actually) to do this important job, but be aware that it=20 > could > take non-trivial time and effort. I see some redisplay tests in tests/manual/redisplay-testsuite.el=20 and scroll-tests.el which seems like it would be a starting point=20 for such a study? >> Conversely there may be further optimization that could be done=20 >> by >> taking advantage of more recent hardware advances such as=20 >> offloading >> to a GPU or utilizing vectorized instructions. > > We try not to use machine-dependent code in Emacs, because=20 > that's a > maintenance burden, what with today's fast pace of chip=20 > development > and obsolescence. Vectorization is generally left to optimizing > compilers, and relying on special hardware, such as GPU, is not > something we should depend on directly. We should instead hope=20 > that > the GUI toolkits and display systems we use will do that for us. That's more what I meant. >> If there's one think I've taken away from my CS education, its=20 >> that >> indeed "premature optimization is the root of all evil". > > The optimizations we have today were definitely NOT premature=20 > when > they were introduced. How much they are still needed today is=20 > indeed > an interesting and important question that still awaits the=20 > motivated > investigators. I have only indirect evidence that some of the > optimizations still do a useful job: compare the redisplay=20 > performance > when linum-mode is turned on with the performance when the=20 > native > display-line-numbers-mode is used instead. Also, we frequently=20 > hear > complaints about redisplay performance, even if you take away=20 > the > problems with long lines. I am a user who frequently wishes redisplay was better which has=20 partly motivated my interest in this. Between displaying long org=20 mode documents with inline images and long lines of generated=20 latex, I'll often see noticeable delay in basic buffer operations=20 such as scrolling. This is also exacerbated by the fact that I'm=20 doing all of this on a Pinebook Pro which is an arm aarch64 system=20 comparable to the raspberry pi. In fact the only way Emacs has=20 been generally usable for me on this laptop is with the=20 native-comp branch.