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, 9 Sep 2019 19:08:58 +0200 Message-ID: <20190909170826.w3ug6iv3fnrxh4jp@Ergus> References: <97f66744-8481-084a-ef23-2c50444e1f05@gmx.at> <20190906093117.25qfim4kcrmiqunk@Ergus> <83o8zw5zh8.fsf@gnu.org> <83mufg5yn1.fsf@gnu.org> <20190908005109.s7hhcczkrcbzewdc@Ergus> <377a8380-af26-776f-de79-2e24cc14e0e4@gmx.at> <20190908125306.mhb2eg7nxjs5z5pf@Ergus> <36b5122a-96a7-b798-1fed-423ea388b772@gmx.at> <83k1ah31fj.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="62181"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: NeoMutt/20180716 Cc: martin rudalics , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 09 19:09:22 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 1i7NAG-000FwE-Sw for ged-emacs-devel@m.gmane.org; Mon, 09 Sep 2019 19:09:21 +0200 Original-Received: from localhost ([::1]:59276 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i7NAF-0004kL-7q for ged-emacs-devel@m.gmane.org; Mon, 09 Sep 2019 13:09:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44977) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i7NA8-0004kE-PF for emacs-devel@gnu.org; Mon, 09 Sep 2019 13:09:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i7NA7-0005sH-4T for emacs-devel@gnu.org; Mon, 09 Sep 2019 13:09:12 -0400 Original-Received: from sonic307-54.consmr.mail.ir2.yahoo.com ([87.248.110.31]:33885) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1i7NA6-0005r4-Dw for emacs-devel@gnu.org; Mon, 09 Sep 2019 13:09:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1568048948; bh=VMdM97unCEJxQs37kQxYoIZ7yf5RP8QfHYcwe0u2uAk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=C+jdCQkQjcHo3IMf56A6t1Pc+vT4vwZ0LSsLNIJUNV0mkG0JKyHg8pRea5ceuBrUNZxFBukIPS9OIKs9xwBDyKGIqIO39jm3Xw+9kwBgo/ofec9NjWaHLYlelij647sfCMOV9Cx4U75NUFOHjVLPfR3kWFyEL/emT4zApYDx929SmsobY2VnKvBuB5sva9I7eIwNeBBSnxVm5qMAjEJOK8gd+eTXT7AvEyZqhJNHuGugEXtXtfy8hDw52RsCSEhceNyODE+vaoIuxP6ybAyvoxuslqPUqlUtIeUXtnCvxUcBSffFlj+/okst+rr8Ant8qqq8yi37Pzc8UqT50UH6Aw== X-YMail-OSG: Q5hjhYkVM1kREahoyLglXcrSAr_TK4yKjHamO4eha2fI0ZdT22YnBrjzMpm.LEC liAOrmTAFc3XMBC8.9GRXLzUMhd7Tvdy3BPdaUlIA5UW5mUnA.MK9fMx9Fyq8HocUxd1Mtbj649A Y3F4ezkLZHUmnp9GMxsGt5SN785iVHNuZX4yVMK.bXyk0mOj3AaRhwoLkWBChgqLV4yZm8ctESt0 YbyZYBtDcPXxTdcdXjF8C1rq0uMPsAlSRJcGU.wdEQPiT4gV6ycL1CjV0lu6gSJrG1sqFtKmfT7H 4E5WAZqB0xFmHLFFvCcSZ4909_k2QWJz1G5xcgQyv5Ri4wVztlpaavv32wl2oJ5KQu7U_ynbNLl. QzUtQmvP1f2X0iMbjwlfOoZp0ngeIeg9TpMOGp0o2x.2dcwNqdc2E6lCRXxFAMeiOQUVxv5RTKE2 SDcN4uK2zCSg46O3Ix1_WkSKIQoE3.nsxmfHezBuiJ9pAIkFegq1tz.8zxtH1.O3R9KJ5F9_qUHI OCwYe6PPnAUo.nh3E0rgoOtrxf5QDLZKrmswHqs7H6o31VaTmrX5lNS21BkeaqvGJOMTHeDvB6s5 XFWiDFPUlMQzevd0Ytz7S..wLwaNUtJVKmKG3R7Xv5G.94xwjgtKkVTpLsBiL4IjZw3zaIMHR8hL i2DFaCU6YphcC564_EWL.G1HWOj1d2yQPNq_9Rw5NL3o5TmxhyTefG_CMm5py7Mi5lipSYNr_yDZ fS4zngX76wJ8.nZlakCJxR3vcB86R9TrugMw9nZPJnN5R6Kf3AgWouwIV_Xosq7QkSIrYL7RLICj bXxrfEkO9tnpU38qsFERAcsSLtXqR2m9MN.bkoPoNA Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ir2.yahoo.com with HTTP; Mon, 9 Sep 2019 17:09:08 +0000 Original-Received: by smtp405.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID c069aded915fa90f62a17684f379ce6d; Mon, 09 Sep 2019 17:09:06 +0000 (UTC) Content-Disposition: inline In-Reply-To: <83k1ah31fj.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 87.248.110.31 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:239957 Archived-At: On Mon, Sep 09, 2019 at 07:00:00PM +0300, Eli Zaretskii wrote: >> Cc: Eli Zaretskii , emacs-devel@gnu.org >> From: martin rudalics >> Date: Mon, 9 Sep 2019 09:39:13 +0200 >> >> > I fixed that, try now please (it is in savannah already). >> >> Thank you. Works now as expected. >> >> I'm still not convinced that it is a good idea to unconditionally run >> handle_face_prop_general from extend_face_to_end_of_line. It will >> penalize processing every line shown in a window even if no attribute >> processed is affected by a nil :extend attribute. > >The penalty is just a call to merge faces and look up the merged face >in the face cache (which, under most usual circumstances, will always >find an already realized face in the cache). If you are worried about >face merging itself, then don't be: we do this in redisplay all the >time when displaying buffers, except in the most boring cases (like >buffer of all-ASCII text in Fundamental mode). > >And the alternative is IMO worse: it will require tracking all the >face changes and deciding upon each change whether it does or doesn't >affect the line extension. Hi Eli: About this; I agree that the penalty should be negligible at the end compared to other things that happens on re-display. But after working on that parts I recognize that the actual algorithm for merge are extremely complicated and some parts are redundant. All the code is full of conditions and branch divergences and the design of faces infrastructure could be more efficient. Code that is used very often like "PRODUCE_GLYPHS" checks 3 if conditions every time (we should unify at least the if/else to bypass directly to the pointer, asserting that it is always initialized in terminal or gui). face_at_buffer_position and merge_face_ref are actually full of nested and nested conditional calls and even (direct and indirect) recursive calls. Some functions that could call merge_named_face I think they call merge_face_ref instead (with the extra checks and divergences). While other "low level" calls at the end also call merge_face_ref (probably for safety) ex get_lface_attributes, merge_face_vectors and so on. I understand that all this is probably negligible... but all that inhibits many optimizations very important these days like code inlining, branch prediction and vectorization. But also a big part of the code is needed just because the divergence between the tui and the gui code... if we unify the interfaces; then an important part of the code will be simplified and reduced and easier to maintain and modify.