From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Ergus Newsgroups: gmane.emacs.devel Subject: Re: Question about display engine Date: Tue, 3 Sep 2019 07:33:33 +0200 Message-ID: <20190903053331.i36bn2i5ytta2ma7@Ergus> References: <83zhjrakf9.fsf@gnu.org> <2aff0873-5d18-a4a0-eada-1ad0e632e753@gmx.at> <83mufr9gya.fsf@gnu.org> <03a80221-5222-9b8b-86a1-67cef18df463@gmx.at> <83zhjp937v.fsf@gnu.org> <8acd9fc1-e6ce-9a86-cfb6-e00a672c154a@gmx.at> <20190901122628.aynhzwwpvqbgyydh@Ergus> <20190902110504.zniyfmd7bi53iyxe@Ergus> <83zhjm7juc.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="270232"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: NeoMutt/20180716 Cc: rudalics@gmx.at, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 03 07:34:17 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 1i51SI-0017zc-F4 for ged-emacs-devel@m.gmane.org; Tue, 03 Sep 2019 07:34:14 +0200 Original-Received: from localhost ([::1]:41580 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i51SB-0003Np-No for ged-emacs-devel@m.gmane.org; Tue, 03 Sep 2019 01:34:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48363) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i51Rw-0003KY-Df for emacs-devel@gnu.org; Tue, 03 Sep 2019 01:33:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i51Rt-0007zx-L1 for emacs-devel@gnu.org; Tue, 03 Sep 2019 01:33:51 -0400 Original-Received: from sonic311-32.consmr.mail.ir2.yahoo.com ([77.238.176.164]:36204) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1i51Rt-0007xe-7x for emacs-devel@gnu.org; Tue, 03 Sep 2019 01:33:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1567488826; bh=ZIoQ19Mqlg6uX1iBNZ+SWi5UNyfYePP/t6YoguvOtGQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=Wpt9N/RvRQxW56fp2YRIZvDwSJXX/130EyL3ePE9dor30x28OEJyWpODpQ1YGxRFZ8gkBltDoJeOi+zR7CkKVNvwAVxJhk4AzIvKvtzrqO+JBQuoXv4PIgjaYgAsrNAdXhjzr+iyvTwQ0v6Bdf77ymj437AZU1b4dpRm8FWILSKYGinYSpnyXfd1sZYAay3sodmVxWdouPPunD4HEJM8wVwStbgr9n3wdNp+PuKi242RZWkBSrlgc0t1NORlwU1rIjdvU4tnkJSFDaLDtBduMzTGLZy8Lhs/pcatKhSqNG7iyXpTjUIOiaNllllKkG8d0r0h1BNpKLXn3OYqU7ts1Q== X-YMail-OSG: _8XmGhgVM1lB8XP1u6gPEZtOfo1uPMnlhUW2hOdfs2KwJlRQ11sowgLzv5oL1hB kSyKF38jdW_nEqZcoCxJmSLW7k4PGMWTK.HacuWEJIUpOG8TOe_AgmS5as6MCvE4NTcyYM0kYvca tanc5wjQvcocMoEz.lCx4MnGGBkcaTBnPN5gc44IF6loAtXpqlDb2TRJWwALTP_JCSqFloGNjzbv FDVddx3xtatgQrbUMGbhoctopZfHaVBtbaOLBlRBs4NCyKDjOmA7woJ_KakBIIA2uVsBJQ4DFZyw 1HDg9ttIuM5eH_doVI6sufte1s9JIWNC_dogqr4k0yOemA7J9o_IfkcnMmXP9FA.aAADPm5a2w_r 44FPAA272RF3Uo8ODPr3rcPBAkIA7lGUR6hIx2zPkrHAsx8_2J7dY4BBpv8w67RM5hUxgr7THtFP jUgsn7CCqpJFzmUP6gCikVZCX2nHZSAjkzIPhSgmnbxJ5KePwI3VORWJgP.2Ypc9uGBU2g7pQqIY MZQjyjUOQMK2S_ousxgEBcMd03qyWWR6kzBgtonJHN9I4eXYtT8c5lPbl4eMbTQYbcB8cLUVyHOC qooS6JaljUm0aOcKFLrqRFYCAdCtEupmHG.BI6OrF8yaSlbCjGZFV1w5Hz.gunm2uK.1tXG3PcsI knRIdHzAMrWRCWzZHZBVTt2FrGOVzomD.XDmfP.v2wOP0_FmhAKfDKCSlhflaz0ubLd3Ja3avJdC zRI0mtFcFW044UfTKDxRMu9croUD2Pc_eb2FDzo7AVV8HIwkwhL544uVkaYhog9LqFfVfJQfPoN_ BoE8ucLJNaUWQm6qBROQg7WBp5gx_bJZzDQOYOvBm9 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.ir2.yahoo.com with HTTP; Tue, 3 Sep 2019 05:33:46 +0000 Original-Received: by smtp408.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID b412d279f7b968a9402c2650eee7709f; Tue, 03 Sep 2019 05:33:42 +0000 (UTC) Content-Disposition: inline In-Reply-To: <83zhjm7juc.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 77.238.176.164 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:239795 Archived-At: Hi Eli and martin. Here I attach a patch minimal proof of concept for the last solution I proposed. At the moment it is not showing the color extension to the end of the line, but I cannot make it extend because it seems like the merge function I added is never executed (which makes no sense but it does not print the messages I added with printf.) Could any of you give a look to the patch to detect what is failing at least to triger the merge and extend? Probably the initialization. (which btw the lisp glue code may be buggy for sure.) Please, any help is very welcome. On Mon, Sep 02, 2019 at 07:18:19PM +0300, Eli Zaretskii wrote: >> Date: Mon, 2 Sep 2019 13:05:04 +0200 >> From: Ergus >> Cc: Eli Zaretskii , emacs-devel@gnu.org >> >> >If so then we might consider the following optimization: The extra >> >face pointer in each face is no more needed after the display engine >> >has processed the face. So we could build a "shadow" face for b+d, >> >keep it in a separate, static face structure and realize a face from >> >that structure whenever we want to (eagerly or lazily). The display >> >engine, when it finds a pointer to such an extra face at EOL, uses it >> >(maybe realizing it on the fly). >> > >> >Also, the merger could nullify the extra face if it's the same as the >> >normal one, that is no single merge step had an :extend false value >> >override a former :extend true value. So the display engine would >> >know beforehand that it does not have to change the current face. >> > >> Yes; in my initial proposed approach the local pointer will be null in >> that case. > >I don't think I understand why you are talking about face pointers. >The iterator doesn't keep any face pointers, it keeps face IDs (which >allow to obtain the face pointer, when needed, by using FACE_FROM_ID). > >So all you need is to have another face ID member in the iterator, to >be used for extending past EOL; depending on how the :extend bits are >set, that face ID may or may not be identical to the "normal" face ID, >the one we have now and use for buffer text. > >> >Last but not least, the display engine has to, after processing the >> >spaces at the EOL from b+d, restore the a+b+c+d+e face as its current >> >face. So we have two static pointers to keep around: One for the b+d >> >face structure (or its already realized face) while the display engine >> >processes normal text and one for the a+b+c+d+e realized face while >> >the display engine processes the spaces at EOL. Can you still agree? >> >> In the display engine we do this very >> frequently. As extend_face_to_end_of_line is very localized we just need >> to save a pointer to a+b+c+d on the beginning of the function and >> restore it at the end. > >Again, not a pointer: a face ID. And yes, we have saved_face_id >member of the iterator for this purpose. > >> And that in X there is some extra code (somewhere) to extend the >> background color using the color in the last inserted glyph (it is >> something happening by default without calling even >> extend_face_to_end_of_line). That code should be removed after this >> change; but I don't know where is it. But for sure Eli will tell. > >It's just that we clear to EOL with the last background color, and >avoid doing that if the background color is identical to the frame's >background. I don't think anything will have to be changed there, but >we will see (I hope). >