From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Question about display engine Date: Fri, 16 Aug 2019 11:34:38 +0300 Message-ID: <838srtpkyp.fsf@gnu.org> References: <83k1bpasic.fsf@gnu.org> <20190807155738.yviofsumjjhqueci@Ergus> <83imr9ar9f.fsf@gnu.org> <0975890b-37b4-428d-f6e5-5dcf894fb6be@gmx.at> <83ftmdapxm.fsf@gnu.org> <20190808083804.ta3evocyb4hirywj@Ergus> <20190808145015.2qaxwzwf4ws2i3er@Ergus> <83ftm98dgu.fsf@gnu.org> <5361a037-d204-b746-790f-ee2ea09459e6@gmx.at> <83o90vu6ws.fsf@gnu.org> <831rxqtnaf.fsf@gnu.org> <7ba80ec4-d7e2-1f69-5b55-00a8c1851cb4@gmx.at> <83k1bhrsji.fsf@gnu.org> <6f3161f8-b007-ae1c-881e-1fad88348146@gmx.at> <83woffrd7p.fsf@gnu.org> <8336i2qwxj.fsf@gnu.org> <020947f5-a8ab-79de-cf74-9dce4cb1572e@gmx.at> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="231608"; mail-complaints-to="usenet@blaine.gmane.org" Cc: spacibba@aol.com, emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 16 10:34:55 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hyXhH-000y80-JS for ged-emacs-devel@m.gmane.org; Fri, 16 Aug 2019 10:34:55 +0200 Original-Received: from localhost ([::1]:51756 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hyXhG-00040A-2S for ged-emacs-devel@m.gmane.org; Fri, 16 Aug 2019 04:34:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50284) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hyXh9-000400-AJ for emacs-devel@gnu.org; Fri, 16 Aug 2019 04:34:48 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:34667) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hyXh9-0004R4-0Y; Fri, 16 Aug 2019 04:34:47 -0400 Original-Received: from [176.228.60.248] (port=4036 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hyXh7-0000nN-Ds; Fri, 16 Aug 2019 04:34:46 -0400 In-reply-to: <020947f5-a8ab-79de-cf74-9dce4cb1572e@gmx.at> (message from martin rudalics on Fri, 16 Aug 2019 09:29:02 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:239394 Archived-At: > Cc: spacibba@aol.com, emacs-devel@gnu.org > From: martin rudalics > Date: Fri, 16 Aug 2019 09:29:02 +0200 > > > Exactly. More accurately, we have 2 problems: (1) how do you know you > > hit the stop point while going back; and (2) where do you go to > > compute the "next" stop point. You don't want to know the answers... > > I'm not sure. If that algorithm is newline agnostic, it will have to > be changed if an eager (see below) solution is implemented. Thankfully and mercifully, all the bidi calculations and hidden state variables are reset at newlines. > > It will increase the cache, yes. Whether it will be significant is > > another question; I'm not sure. > > In the worst case it would double the size of the cache for > implementing the background extension alone. This looks like a > veritable ordeal to me. IIUC we do all this to keep the display > optimizations (where we compare the glyph matrices) simple and > efficient. Or is there an additional twist to it? Well, a face cache is rarely too large, it mostly holds a few dozen faces. We also clear it from time to time, so I don't think this would be a catastrophe. > One could argue that if, in the current implementation, the display > element stops right before a newline character and that newline is, > presumably, a separate display element, the overhead remains > unchanged. But AFAICT, font locking does not necessarily pay immense > attention to newlines (Lisp comments and C strings excluded) so at > least for displaying programming languages the overhead increase might > be significant. Actually, IME the situation where a face crosses a newline is somewhat rare. > >> Since extend_face_to_end_of_line already switches to the default face > >> when no extension of the region is wanted > > > > It does? where? > > I thought it did so here > > /* The last row's blank glyphs should get the default face, to > avoid painting the rest of the window with the region face, > if the region ends at ZV. */ > if (it->glyph_row->ends_at_zv_p) > it->face_id = default_face->id; > else > it->face_id = face->id; > > but apparently that's only a red herring. This is a corner case, for the screen lines beyond EOB. It is none of our business for the purposes of this discussion. > I currently see two ways to accomplish that: Eagerly, during face > merging, we would have to search for and possibly create the extend > face variation whenever the next stop point finding algorithm > encounters a newline character within the object it examines. Not my preference. It will disrupt the neat algorithm of walking the interval tree, or at least will force us to also search for a newline (which is very fast, but still a complication). > This means that any display element that contains a newline > character also ends before that character and the entire logic of > finding display elements changes. What you call "display element" is actually called a "glyph string": a sequence of glyphs that have the same face. The division of glyphs into glyph strings happens as part of preparing glyphs for display, and will automatically pay attention to changes in the face ID. So no logic changes here. The changes are as I described above: where we compute the next stop position. there' we will have to see whether the stretch of text till the next stop includes a newline. > A lazy variant would have the display engine itself create the extend > face by demand whenever it encounters a newline character within the > current display element. I'd prefer this method. Two reasons: (1) it is localized to the code which may need such a face; and (2) it scales better, because the display code is frequently invoked on short portions of the text, so there's no guarantee that it will actually get to producing glyphs with the "extension" variant of the face, so realizing that face in advance might well be waste of unneeded effort, because the additional face will never be used. > The worst aspect of all this is that there is no simpler solution even > if we attempted a different implementation of the extend logic. > Suppose I used just one single, global variable to turn off/on any > face extensions. For turning it off, I'd still have to, at the end of > every line, assure that a separate realized face does implement the > "off" interpretation while the "on" interpretation is already provided > by the last face on that line. Right? Yes, we will typically need that "on" face for the next screen line.