From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Question about display engine Date: Fri, 16 Aug 2019 09:29:02 +0200 Message-ID: <020947f5-a8ab-79de-cf74-9dce4cb1572e@gmx.at> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="238036"; mail-complaints-to="usenet@blaine.gmane.org" Cc: spacibba@aol.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 16 09:36:45 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 1hyWmx-000zhn-Ph for ged-emacs-devel@m.gmane.org; Fri, 16 Aug 2019 09:36:43 +0200 Original-Received: from localhost ([::1]:50480 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hyWmw-0000jg-AS for ged-emacs-devel@m.gmane.org; Fri, 16 Aug 2019 03:36:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37643) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hyWfn-0002ia-Lg for emacs-devel@gnu.org; Fri, 16 Aug 2019 03:29:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hyWfi-000754-Ch for emacs-devel@gnu.org; Fri, 16 Aug 2019 03:29:19 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:39987) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hyWfi-00074N-0W; Fri, 16 Aug 2019 03:29:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1565940543; bh=4XPSzLx2Mz7Fj5eLgifDiCUwu6TGhca4S2B6SZ73NEA=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=EYLhgUy/lv27GAHCr2LIQ3LDw+DAGqKmBHaCDOsZOi9ZO7C7y1/LKEEXEYQasICHE GUpRJsRYGT3Bc5UXQF/IWt9HFHABK9/brgy0XZGbp2OTBGKnrc75yJiWHmuVniHZbs 9OZT8w44kd3J5kBNw7jBhqsUzSMZKgkf1vLo761s= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([46.125.249.86]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Lt1S6-1iQfQL1WA6-012Vcz; Fri, 16 Aug 2019 09:29:03 +0200 In-Reply-To: <8336i2qwxj.fsf@gnu.org> Content-Language: de-DE X-Provags-ID: V03:K1:B5XwJA4dLDZGnHyvJuogzQB8SEsM1cEXKjV+4MYFCTQCnqOg/JO TZdu00X+5mvJb7hQMDLB2reNn/4wLcN12mW4WThv4x1RDnz7DVlVGNZ878HyhwQ/P/UzkKJ cHlTkNf4/0MdjUeyZIfmsDUg8nKQVhDBJRYImiI8KEe67qfRFWOD8yauymwiF9I8H4gw3Ri NgA7y/2hQlS6I/N+j42CQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:nJ3c7janbeM=:mLM16zlFURxGTbJU+i5M2H e6JCMwMiNqzfC1BSFlYs63ILaVp40whekWWj9zR90QjCxgHIpGAGxUPMlT9ELd+XIRIL4hrpM np1Qfy9mjclyqlzMRnD1CvN3SpkrS115EXq8XQoGlElPjLVelKJhulLS7fEWALSBDvyKHAbIZ h+qpzbEQYHra1bclRBYFMTNsr85oso5k1duvR8jMRVQFfEQes6q6KH46einUBYPw7YqED29WQ VDwbOYmMcehow+RU0ktc8lMXMq6hhVc1EpXL452tou5rjNYlaYiZPG9r3xbj9J8fCdjXuoJ4O Vg/g/NhljAgxma5uCdRyIkCMK19wsMAkfsmZU6RrnNBCPxsVJ/ygGRJY+/xIJ5r6GlXMxP8Fu 632izrjrFsRffXThaNR3cO0IPI6RVHz9wMnDl0wqfFRKDaIdyv/y19bbAw4Sb/n/t5o84jtjx w3LQSne5Q480z52jAJ/ZjW4gE6TlcZxeEOCuumKkjL+d0ZkK5g2FFFx+eCd5c2a/eChsFV3RL lrbKMJURtm5CHTtqDEdPox85rVqxsQcUqzZJ+AcHDTVfJYURT5I1I9jeMwN2rePXQqlscTEeG nQile78zIGYI58/uW3mWj9FRekYiewsmHxhy5VpGi0dz3eIGOdfolPrjlGBBg8qnSXqUpLISL 1/LrBaNmEVYPW2IRrjcPGVxDlmJSCbIsDpgPS67Fj63UEO3c5vd6jyTOXOg2+luv+Z3IZ8VMG hsMTgX8GHXdLHaDjGMBGpfIL+AC702PY/b3fs3Jbl1oJZ1s8GdkNItrlRBiOCLkeQHXNnVCM X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.15.19 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:239393 Archived-At: > 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. >> ... I obviously have to discontinue disagreeing with that conclusion. >> But wouldn't that significantly increase the size of the face cache? > > 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? 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. >> 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 =3D default_face->id; else it->face_id =3D face->id; but apparently that's only a red herring. >> it could also switch to the default face when the extend_background >> bit is false. Right? > > No. A face is not just its background color, it's quite a few other > things. You only want to reset the background color. For example, if > the face of the last character used a larger font, you still want the > extension to use that larger font, e.g. for the fill-column indicator > character. > > So switching to the default face in this case is wrong, we really need > to make a face exactly like the one we used, but without the attribute > that should not be extended. 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. 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. 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. This would strike me as more elegant but also means that the display engine has to scan the face cache and potentially realize a new face here. 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? martin