From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Rethinking the design of xwidgets Date: Wed, 14 Oct 2020 17:33:37 +0300 Message-ID: <83362g27y6.fsf@gnu.org> References: <864kmzupp0.fsf@akirakyle.com> <835z7e2ouj.fsf@gnu.org> <86v9fet5sg.fsf@akirakyle.com> <83imbe1040.fsf@gnu.org> <86pn5luak4.fsf@akirakyle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8752"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Akira Kyle Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 14 16:48:42 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 1kSi53-0002Bj-PN for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Oct 2020 16:48:41 +0200 Original-Received: from localhost ([::1]:42826 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kSi52-0000Sb-PR for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Oct 2020 10:48:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37516) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kShqK-00007o-NT for emacs-devel@gnu.org; Wed, 14 Oct 2020 10:33:28 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58715) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kShqJ-0005yy-Ow; Wed, 14 Oct 2020 10:33:27 -0400 Original-Received: from [176.228.60.248] (port=2940 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kShqJ-00057A-4K; Wed, 14 Oct 2020 10:33:27 -0400 In-Reply-To: <86pn5luak4.fsf@akirakyle.com> (message from Akira Kyle on Tue, 13 Oct 2020 14:37:31 -0600) 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:257635 Archived-At: > From: Akira Kyle > Cc: emacs-devel@gnu.org > Date: Tue, 13 Oct 2020 14:37:31 -0600 > > > I'll need to read up on those two topics, but in general, as > > someone > > already pointed out, the Emacs display of images supports > > interactivity by letting you call functions triggered by mouse > > gestures on the varipous spots on the image. If such a function > > produces a zoomed-in/out image and displays it instead of the > > original > > one, wouldn't that fulfill the need? E.g., we already support > > animated GIF images and zoom-in/out by mouse scroll, so it is > > inaccurate to say that we can only display static images. > > Can actions be triggered on a click and drag as one would do to > pan within a plot? I didn't have time to try that, but just looking at the code, I don't see anything that makes the clocks on images special, so I'd 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. > As far as I know there are really only two FLOSS PDF libraries out > there: poppler and muPDF. Between them poppler supports more PDF > features and seems to be more widely used. I agree this isn't > really as compelling of a use case for xwidgets, but I seems like > it would be easier to achieve better PDF rendering via xwidgets. I can see how that is tempting: the image handling is taken care of. What I'm saying is that this advantage should be carefully weighed against the disadvantages and difficulties in integrating such self-managing objects into the Emacs display code. > > E.g., the kludge in dispnew.c around line 4365. It disables one > > of the most important redisplay optimizations in Emacs, once you > > build with xwidgets enabled. > > Ah, I had briefly looked at that but I wasn't sure how important > it was. I may be able to make some progress on that but it's hard > to understand the context for that function. It seems like that > function is responsible for an optimization that avoids redrawing > glyphs if the window is being scrolled by copying them Not only if the window is scrolled, but also if the previous display can be converted into the current display by scrolling some of the stuff that is already on the glass. the algorithm is a basic comparison of the current and desired display, similar to what the Diff utility does. > however I couldn't find where or how the glyphs are actually copied? See the calls to rif->scroll_run_hook. > > I'm not trying to scare you, mind you, just point out that the > > ideas you have should probably be talked through in mode detail, > > to see that they are workable. For example, did you study the > > various window-redisplay optimizations, and if so, did you think > > how the widgets will adapt to them? > > I'm just starting to dig my teeth into some of that. However I'm > wondering if anyone has more recently tried to quantify the > improvements the various redisplay optimizations make to both > actual and perceived render time of Emacs. For example the comment > on the scrolling_window function in dispnew.c that you pointed me > too references that it is implementing an algorithm from 1978, > perhaps it would be worth exploring if there are any algorithmic > advances? I don't think that algorithm is less optimal nowadays than it was back then; the really interesting question is how much it saves us when compared to simply redisplaying all those lines. > It strikes me that perhaps some optimizations may no longer be as > necessary on modern hardware or on GUI displays as they were 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öllmann, who developed the current display engine, did add optimizations one by one until he got reasonable redisplay performance. Measuring the speedups from each of the several optimizations is an important job, but it's a large job. For starters, one needs to come up with a large enough and representative enough sample of redisplay use cases, and that is not easy. So I'd encourage you (or anyone else, actually) to do this important job, but be aware that it could take non-trivial time and effort. > Conversely there may be further optimization that could be done by > taking advantage of more recent hardware advances such as offloading > to a GPU or utilizing vectorized instructions. We try not to use machine-dependent code in Emacs, because that's a maintenance burden, what with today's fast pace of chip 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 that the GUI toolkits and display systems we use will do that for us. > If there's one think I've taken away from my CS education, its that > indeed "premature optimization is the root of all evil". The optimizations we have today were definitely NOT premature when they were introduced. How much they are still needed today is indeed an interesting and important question that still awaits the motivated investigators. I have only indirect evidence that some of the optimizations still do a useful job: compare the redisplay performance when linum-mode is turned on with the performance when the native display-line-numbers-mode is used instead. Also, we frequently hear complaints about redisplay performance, even if you take away the problems with long lines.