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: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets) Date: Fri, 04 Dec 2020 09:48:24 +0200 Message-ID: <835z5if1vb.fsf@gnu.org> References: <87mtyw9c7f.fsf@logand.com> <83r1o7eyya.fsf@gnu.org> <87360my554.fsf@logand.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39363"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Tomas Hlavaty Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Dec 04 08:50:32 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 1kl5rL-000A89-Ei for ged-emacs-devel@m.gmane-mx.org; Fri, 04 Dec 2020 08:50:31 +0100 Original-Received: from localhost ([::1]:60074 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kl5rK-0007ZN-GM for ged-emacs-devel@m.gmane-mx.org; Fri, 04 Dec 2020 02:50:30 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48820) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kl5ph-0006hF-Kc for emacs-devel@gnu.org; Fri, 04 Dec 2020 02:48:49 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33229) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kl5pg-0007AH-UD; Fri, 04 Dec 2020 02:48:48 -0500 Original-Received: from [176.228.60.248] (port=3450 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kl5pb-000283-IR; Fri, 04 Dec 2020 02:48:48 -0500 In-Reply-To: <87360my554.fsf@logand.com> (message from Tomas Hlavaty on Thu, 03 Dec 2020 22:02:47 +0100) 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:260272 Archived-At: > From: Tomas Hlavaty > Cc: emacs-devel@gnu.org > Date: Thu, 03 Dec 2020 22:02:47 +0100 > > >> The images do not travel via pipe. Only meta-data like filenames, > >> coordinates and handles. > > > > Yes, I understood that much. But that doesn't matter: communicating > > with a spell-checker in the flyspell-mode case also sends just a small > > number of words in each direction, and yet the slow-down is > > considerable, sometimes downright annoying. > > Is it an appropriate comparison? Yes, IME. It shows what happens when Emacs needs to communicate with an external subprocess at a high frequency. Which is what will happen if your proposed design will be used as a general-purpose feature for drawing images in Emacs. > I do not intent to scroll through a large buffer with lots images. Even > if I did, there is no evidence that it would suffer the problems in the > above example. w3m manages just fine. My use case is something like > image-mode or doc-view or pdf-tools. emacs-framebuffer already does > that for many image and document types and I have no problems with > speed. So you are talking about making Emacs support only your use case? Not about a feature that allows any other legitimate use case in Emacs which could involve images? > > Sending the image spec and receiving the dimensions and other image > > attributes, yes. And I presume that the sub-process needs some time > > to calculate the answer (because at least some queries require to load > > and process an image). > > This is a non-issue. Images usually do not change those attributes > quickly, if at all. So this can usually be cached or even calculated > just once. That "once" is what I'm talking about. Imagine going through a directory of image files one by one. > Again, my use-case is like that of image-mode, doc-view and pdf-tools. > There is a file, say /tmp/a.png, I open the file in a buffer and the > buffer will show the png image. Or there is a file, say /tmp/a.pdf, I > open the file in a buffer and the buffer will show the pdf document. That's a very limited use case. So much so that I doubt if it's even justified. After all, you can already display images on the console, so why do you insist to show it inside an Emacs window, of all the places. People are already complaining about the limitations of doc-view and similar modes. > > Emacs doesn't draw anything because it knows what's on the glass and > > what _should_ be on the glass, and compares the two to decide what > > should be redrawn. But you want to draw on parts of the screen behind > > Emacs's back, so it won't know whether something changed. And you > > OTOH have no way of knowing where Emacs have redrawn something during > > the last redisplay cycle. So you will have to redraw your images each > > time Emacs finishes a redisplay cycle, regardless of whether it > > changed anything on the glass in the area of an image. These > > redisplay cycles happen at very high frequency -- usually, Emacs > > enters redisplay, quickly decides what needs to be redrawn, and then > > does whatever has to be done and exits redisplay. It tries very hard > > not to redraw the parts that haven't changed, and that is why there's > > no flickering. But I don't see how you could prevent the flickering > > of those add-on images, because without knowing which parts of the > > screen changed, you will have to redraw them very frequently. > > This is not an issue. > > You can try and see it easily. > > Start emacs on the console. > > Start shell in Emacs: M-x shell > > Execute: $ cat /dev/urandom >/dev/fb0 > > Observe what Emacs draws. I can see blinking cursor. Part of the > *shell* buffer was drawn and line and column indicators on the > mode-line. Everything else remains unchanged. What you don't see is the frantic activity going on in the display code behind the scenes. Look, you can disregard what I'm saying and then later learn this stuff the hard way. It's okay, it will be a fine journey and very educational, I can assure you. I'm just trying to warn you about the hidden rocks under the surface. I will stop now.