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: Sat, 31 Aug 2019 09:29:13 +0200 Message-ID: <03a80221-5222-9b8b-86a1-67cef18df463@gmx.at> References: <20190819161305.uwlgsm44yjrmul3o@Ergus> <83pnl1kskj.fsf@gnu.org> <20190819213024.ciukp34xmgrzh7yn@Ergus> <83imqskjyb.fsf@gnu.org> <20190825102205.rxhmu3bukraywhok@Ergus> <83lfvhh6dn.fsf@gnu.org> <20190826043145.pm5aplrxna5hwcso@Ergus> <83y2zgfjzs.fsf@gnu.org> <20190826081819.cuhm3tpw3lq3m5jh@Ergus> <83mufwfe8o.fsf@gnu.org> <20190827222025.p2cbjwak4ysi3ept@Ergus> <3ea328a6-2b35-5a01-77a1-bbf9ff7f16f2@gmx.at> <83lfvdd5f7.fsf@gnu.org> <83woexb3yu.fsf@gnu.org> <160dfd3f-60d4-8758-df65-2165c552f39e@gmx.at> <83zhjrakf9.fsf@gnu.org> <2aff0873-5d18-a4a0-eada-1ad0e632e753@gmx.at> <83mufr9gya.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="252059"; 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 Sat Aug 31 09:33:02 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 1i3xsb-0013Pi-FQ for ged-emacs-devel@m.gmane.org; Sat, 31 Aug 2019 09:33:01 +0200 Original-Received: from localhost ([::1]:42882 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i3xsa-0006oB-6P for ged-emacs-devel@m.gmane.org; Sat, 31 Aug 2019 03:33:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34279) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i3xp8-0006kL-8A for emacs-devel@gnu.org; Sat, 31 Aug 2019 03:29:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i3xp6-0002WV-JD for emacs-devel@gnu.org; Sat, 31 Aug 2019 03:29:26 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:56165) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1i3xp6-0002Sf-6h; Sat, 31 Aug 2019 03:29:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1567236555; bh=/jVibd1YYQw0fMhXwRf1KFQsaJW6kiaZP6PdYCv9aQo=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=UFffoqOWwV2+1m3viEToN5SPJ360j+AyYD6IKL+REObZ6NQ5nNqalHlBYJU9IRXal MFCPT1g4kfwYlGns0LLQakntjv8SAxd6RzivvEhA//PfYm1l00QWbZJRMNcQ60pIUS x+qWmeHtAh4KkpeUvWC28X5rRm79CLIHM1pUx9jo= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([213.162.73.161]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Ml6mE-1iTNUF0J9o-00lX2u; Sat, 31 Aug 2019 09:29:15 +0200 In-Reply-To: <83mufr9gya.fsf@gnu.org> Content-Language: de-DE X-Provags-ID: V03:K1:EfAMXbgrSus/rOSOoYdkMFXfiJh60k1nsunAeHlrieInYEHggIM nz9tAuM0AgdLp7/6CzjIiKLdIGk3KWGDSG81ahOi1GGKDNF2C+ugRNnKV0TWKdTigIbEewm J4kJ7Nedc68Vv2yxViJEL+PgYXYWQ+BqsGedJM97zen3RMjSCBBSDMw2GNIwjPJOQ1FoUrS BRH1iMsSfQK6jWOxGFqAw== X-UI-Out-Filterresults: notjunk:1;V03:K0:mfqVfzXE/Ho=:WiEXminWnuJkhgfvomHu/D 4y9Hkv3bnv0K5pd+FI7jsy5iwsDCToHMmTuKUrCbP1SltnzTrKFmkNKFH0yXD5rlqOyxQibP8 GkzLD6VRDU62RVtk0lsO3a1F5AKFLOWRlmEacWaUSaN9taSgYrptRdVH/P9aVh1gWZGTZG/FO DORXW6uxIkIllGQIAWYBnoGgbIY1FufydG/MFpCbANiih69FiUx4l8W9/XOGlqKJtPQdM3idK s5QswxyjSVlPjmGvICZXW8aI/CODevnlWboeE6PBfgBC/5tdZB8F34ycsz5ll1qTR9O5RH9mz 5slQlTKRSVfWePDd1sEIjRjpXwo6bgVBI8rJw8bDl1pxmgep636CYbl9Puzntq5uTYG5iqzrI WbCPtob75VHdp6r3oJzsF45jMu9KvKu1vfkCn3IoKXWctwLuGY2e1tlSb7WarLaq2fAvHbEKW q3z9m3Q7qmgJZXO/gzxFVG00whpUs8aERCwKGuuUGs8SRfgILx4mJmveWD2szUrVqduX/ckXW 4sDxy06b0yLuxUIjG+YOyBq2eMbu8tY0zkWQcKzIHCBGPEABxJ2arPHJqZz0XDeq/FHJPEzwx NXxm7MjTyDRiPdjEX9ObxO/ytqb0v3K1YzGsUCqR1bXtkYCJajFOseAjiN9NTalHBSXMh3q8W JEXF5iOrKuqvLGqRorQQ38dFGh9bSW+KvND2OVfk2uQlf4QDKlcKLcvkBrmIBV2iRJDBUwGG4 uHTjcZa0ulkSH9ohDR4mgHL5SQnjDj82o+iu8Z6RoMq7PiuZ2q13rBVQ0ECMlgzk75Wj7OYE 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:239718 Archived-At: > I thought we already agreed that there's no other way of having this > feature than to realize a face at each EOL. Then that's where we have been miscommunicating. The whole idea behind the extend_background, extend_underline, ... bits was to avoid the full handle_stop rigmarole at EOL, like finding the overlays and text properties and processing them in the right order. All this was already done at the last "real" stop position encountered by the display engine and has not changed since then. The only missing step is to process the :extend attribute of any face merged. For the normal background, this is the value of the :background attribute of the last face that specified that attribute and was merged in. For the extended background this is the value of the :background attribute of the last face that specified that attribute, had the :extend attribute set and was merged in. To put this into praxis, the face merger would maintain a shadow copy of the background value. That shadow value would not get overwritten when merging in the :background attribute of a face that does not have the :extend attribute set. Eventually, we would wind up with two, possibly distinct values of the background to realize - one for the normal and the shadow value for the extended background. If we wanted to realize both faces - the one to use for the current face and the one to use for extension - immediately (eagerly as I coined it earlier), we could do that right after merging terminates. We probably would set up a pointer to the realized face to use for extension, so the iterator, when arriving at EOL, would find it right away and make it current. That's all. But we probably don't want to realize the face to use for extension immediately and do it - as we agreed earlier - lazily when the iterator arrives at EOL. In my region/comment example, the comment could have terminated before or at the EOL where it started, resulting in a new stop position and we would have needlessly realized an extended face. Initially, that's where I wanted the extend_background etc. bits to kick in, just that I wrongly thought that filling the end of the line with the background of the default face would be sufficient ... Note: We could also try to find out whether there _is_ another stop position before the next EOL after merging faces and, if there's none, realize the extended face eagerly, but I'm not sure whether this idea can be incorporated easily. >> But they would still have to fully realize the face to use by merging >> all faces at each newline. This means we can do away with all those >> precalculated extend_background, extend_... bits because they cease to >> contribute anything to the solution. > > I don't think I understand what the "precalculated" part refers to. Is it clear from what I wrote above? The extend_background, ... bits would remember the precalculated differences between the attributes used for normal text and those for the extensions. >> The only practical solution I see is to, instead of extend_background >> bits, use extend_background colors. In my example, this would mean >> that when, at the stop position prescribed by the comment start text >> property change, the face merger sets the background value of the face >> to realize to that of the region and the extend_background value of >> the face to realize to that of the comment. The display engine would >> then realize the face for writing the remainder of the line right from >> extend_background instead of from background + extend_background. > > I don't see how this will help anything. To remind you: the display > engine manipulates face IDs, it doesn't know anything about the faces > themselves, and in particular cannot magically exchange a face's > background color for some other color. But it knows where the background of a realized face is stored and could easily realize a new face which is the same but for a different background swapped in. Hardly rocket science for the display engine. So what we could do is to simply maintain a vector of the values for background, underline, etc. calculated at the last real stop position and whenever the display engine encounters a newline, realize a face with the values of that vector replacing the current values, use that face for the spaces at the rest of the line, and restore the old face for the normal text on the next line (unless we have several newlines in a row and similar optimizations). > I don't think I see the tunnel. I thought the issue was resolved when > you posted your summary up-thread. What am I missing? When you saw my proposal to use a number of extend_background, extend_underline, ... bits, your crystal ball should have complained that multiple bits are useless because we would have to realize a new face anyway at EOL. A single flag (if at all) could have been set by the face merger to detect the case where an attribute without the :extend attribute set overwrote an attribute with the :extend attribute set. In my region/comment example this would have happened where the no-extend :background of the region face overwrote the extend :background of the comment face. The display engine, whenever it encountered the flag set at EOL, would have triggered a new face merge (and avoided it otherwise). That single flag approach wouldn't penalize the display engine if attributes were extended by default. In that case, the re-merging step at EOL would be needed only in cases as used in my region/comment example. But if, as Ergus requested earlier, we did _not_ want to extend attributes by default, the re-merge penalty would practically happen at each EOL. BTW: One problem with Ergus' proposal is that hacks like the one proposed for Bug#15934 won't work any more. For that bug, we could obviously set the :extend attribute of the respective highlight line face but all instances in the wild using the same hack already would be affected by our change. martin