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: Mon, 2 Sep 2019 13:05:04 +0200 Message-ID: <20190902110504.zniyfmd7bi53iyxe@Ergus> References: <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> <03a80221-5222-9b8b-86a1-67cef18df463@gmx.at> <83zhjp937v.fsf@gnu.org> <8acd9fc1-e6ce-9a86-cfb6-e00a672c154a@gmx.at> <20190901122628.aynhzwwpvqbgyydh@Ergus> 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="81522"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: NeoMutt/20180716 Cc: Eli Zaretskii , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 02 13:06:40 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 1i4kAS-000L5w-Es for ged-emacs-devel@m.gmane.org; Mon, 02 Sep 2019 13:06:40 +0200 Original-Received: from localhost ([::1]:35120 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i4kAR-0007bT-3G for ged-emacs-devel@m.gmane.org; Mon, 02 Sep 2019 07:06:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60407) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i4k98-0007ZP-T5 for emacs-devel@gnu.org; Mon, 02 Sep 2019 07:05:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i4k97-0008VX-1T for emacs-devel@gnu.org; Mon, 02 Sep 2019 07:05:18 -0400 Original-Received: from sonic313-20.consmr.mail.ir2.yahoo.com ([77.238.179.187]:36741) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1i4k96-0008SM-SM for emacs-devel@gnu.org; Mon, 02 Sep 2019 07:05:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1567422314; bh=sGskP18uFZJPG8xuv3Hc5CvTw/jJhiEWsQ+xn/8hHns=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=RB8o5ZD5S8gSy/Dd31xMAN6fXvCXcHl/uVSg/EEXVBj5TJaf6n5Od/xfOLfQBYy77uXuwYa+FZqS7uiC6GxgEO+a/JUZDrRdwpn1pgIxC3W1v3Sm77IC1X6JqMgzxbPisIDLd7sfHumEetOhmQ8Cl6gbNefkZKMhXGbj0lFaNzvvoej4ct9SG7JjE7ecS2dwbuuyEiEs+EGpyZ0GzDTebYNZm5IAENmYT9Vsit1/1j7jI5LCI8f8t6nSagkcv33XN6sbS8cnPHAYI1e7MQBoCOvhQkIGzRmhpT8oP/XmbyiGbrYobJhXbUrS7namEIlH8un4ttPQxo90AGPE/EWDTg== X-YMail-OSG: 1EMRmDAVM1mPpZ.YLzvoY9koyiyIuQdxnz75CBUOK0HQend3OUZ_yaMBDVMPo_Q OhyybFx43DHjuG6hTSK_MWHCWmC0uHDMeKkTPGQdj6aCDqe7csANz9jOLCwJ.Cfs1.IUcqJDzzme oJNYax_gQKQ8Na9p5JY4txy6WVXlkCVHts0OHihTfJo_zGtVjr9Yrfw9JtLVq6yWDB_JhIW0eolG YcrflxBBa26u8eMu0Oxprntj1Ox0RIpdFoK1R8ZnMBcfZP54VNJ54oW6cQl6_YhbyTLaCMVI.nTw bkN1IETog.PvyPqt04tTyVnbqxkEXMTKL7zKF9aZjFfaO8BxvUZ.HKCWicCZGp0HOT1pA20R9rY2 qBsI7Q3AVWdY93ngHx6E8pZXWN_8Av_MBgVBOtuIfKRX7d3oIvUk_FMFF3yJps5dNpOjQbiqLf0Q rfa0JcvMJYOioemw5Qkk4tJ_e8SiWU_5u2X8kKpvzGNcKsDc3luVEts9trArG_damTyfVrW7G3Tl O8W0JHv3e_Ot5MbUv5EVlJTdRBGfgN3hZoVv6NTVJxHcNc59yiXmSHQc5l8Y36OrvSrX9tj4.JV8 qUIlNHcO1VC1wKAxjH_zD3JMl1mJo5Fb2NV1wjdMTIFpIswJNBHnY77Oc0NjKjfwn36mDE4rcx.Y zwY2XnXi4wP_Y579d4n3DchiQYbEQonU86xUDWnAzPUFfgiJpAuRPcTG0UGi97bzru9x1YQXgw8W EpKysTmLMjJcruhwktVDOE6wr07ap52kF4ELzYwG8Sv7gR8yywv6esIMxbxY67Ok62FxFPNGsBTe hlQhLKSFG87JDZ73Qcsto0EVL3ZivXpuJThAoBHDTw Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ir2.yahoo.com with HTTP; Mon, 2 Sep 2019 11:05:14 +0000 Original-Received: by smtp421.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 8b8b195c83174f6175635ceab38358bd; Mon, 02 Sep 2019 11:05:10 +0000 (UTC) Content-Disposition: inline In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 77.238.179.187 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:239772 Archived-At: On Mon, Sep 02, 2019 at 10:36:34AM +0200, martin rudalics wrote: >> I have been thinking about this a little bit more and it seems like we >> are trying to replicate a behavior that is already there. >> >> If we had an extra face pointer within the face struct initialized to >> null (or default face), and then when we merge and the extend attribute is set we >> initialize it to the current merged face and we transmit that pointer >> from merge to merge until we have a new face with :extend, so we merge >> then those two... I think when we reach the end of the line we will >> have there already all the information we need. >> >> Lets say we have a sequence of consecutive merges (a,b,c,d,e); but only >> b and d have :extend. >> >> At the end we will have in the merges: >> >> (a, a+b, a+b+c, a+b+c+d, a+b+c+d+e) >> >> but with this pointers in them: >> >> (nul, b, b, b + d, b + d) >> >> Which for me it seems to be what we expect to have right? >> >> Does it makes sense? > >I think so. Now the realized face for normal text is a+b+c+d+e and >the display engine would use it right away. When the display engine >encounters a newline character it has to "switch" from a+b+c+d+e to >b+d. But it has to assure that b+d _is a realized face_ because a >reference to that face is the output expected from the display engine. >Any additional pointers like yours would be ignored after that. > >Do you agree so far? If so, then the question remains _when_ to >realize b+d. Eagerly, when the face merger has done its work, or >lazily when the display engine encounters the newline. Eagerly has >the advantage that the display engine has all the faces already >realized. Its disadvantage is that when a new stop position is found >before the EOL, the b+d face was realized needlessly. Do you still >agree? > I think any of them is still a good trade-off because it is very use-case specific. When coding and with the actual wide screens; in most of the cases the lines are always extended, So I don't think there will be a significant difference. In any case we could implement any of them more or less with the same complexity... > >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. >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. It is a bit more complex than that because the code for gui and TUI is in different portions of an if condition, but this part is almost the same I made in the first patch I proposed. >Can you imagine any difficulties with implementing such an approach? > I only see small details like that in some cases we need to reinitialize the extend face and the default-face value maybe is not the right choice in all the cases (I need to look into it a bit more). 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. >And we would have happily put to rest all those crazy extend_... bits >I proposed earlier. > >martin >