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 21:29:34 +0200 Message-ID: <20190909192934.7sysej7ladlefunb@Ergus> References: <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> <20190909170826.w3ug6iv3fnrxh4jp@Ergus> <83d0g92vgs.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="125809"; 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 Mon Sep 09 21:30:31 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 1i7PMp-000WZW-Kj for ged-emacs-devel@m.gmane.org; Mon, 09 Sep 2019 21:30:28 +0200 Original-Received: from localhost ([::1]:60238 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i7PMo-0007R1-9b for ged-emacs-devel@m.gmane.org; Mon, 09 Sep 2019 15:30:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46379) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i7PMF-0007Qj-0P for emacs-devel@gnu.org; Mon, 09 Sep 2019 15:29:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i7PMD-0002cu-Hr for emacs-devel@gnu.org; Mon, 09 Sep 2019 15:29:50 -0400 Original-Received: from sonic306-20.consmr.mail.ir2.yahoo.com ([77.238.176.206]:43753) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1i7PMD-0002bK-9J for emacs-devel@gnu.org; Mon, 09 Sep 2019 15:29:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1568057387; bh=9/USkP9Nndgj4pJtvdF5mZH3TeQbSCuO+3V6J0/m2yI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=axTPA8SqVho1hz3FuLEsv08l/acjxpaoaPBYFm2TQ7jAkNHDthqzenDsVAurmsmuMCLSsri59FMN4btWRbIwJywEdNg05roCUhJwnDc32yC+5cjlOwoQNHRDuNgjJgWAa4hljwZDEYSHcpt3xO5myDESDAZhAhLaZSd0QVxg2EIyvO6a6gdDwfaJp6ElxHuHQlIZLhdNrskwhQOw5BWn930B3V/JI5f27SQwOJ+wpOeVPNnj10wKKXQEoRtv5Ydp73Ln3XEEhcn7zKouNtI9mm7HwaTr2f3gNDXUAo/bguKoKIN2SPFneOUudjy6iPYbrVcDgy1KEpY8h5srlXROpQ== X-YMail-OSG: Ti5xt7UVM1n6CZZzR7IatVDck9MToK4pN1N3tda6r61QIGQj1G3tXcABqv554iX jCxdxyhHIBHRBWS7wkK6Uw8CW85OdG3.maqxoXpaT_HfdUM94uDk.F0T5_ECGq7qGYegiNIzjLY_ sMr0LZuXv3GwSP6dchP0dHU_xiCDxB2s6KlqA05D_oiW7tXJtxBfB74we1FyUcSAsnahVjt.XqH8 ZnFgHLpJFCocmfwB2oQseTBfHx1B4vedYnVZQhLNosEhmJ063wQvrG5EZM4xpTMN9yXUiX_.EvXc xDkoEXllCnlEh.IIwLp1l59rkd7.RSLnovnsprpNLMkrNTeUcGSvlzru_jsNL5YRLLc8.wHZTgyN bmQGaRHwkuZWIqpzidkFTQpRU0TH2yNwgV6S2F2pbUQHllAK4gB4VCMZrRIbTLmHQeoZ__J7kTgN tvmgBjBMZ4fMgI8z_S8rmkAHq6YTbATWbtQzHGl9o4ORMXgs4pt4RtjGNZKTN4fQDavMlO90JW4G QmMHiYhkdL9v0MQg12.T1RX4qqFPeC1aar07H5TSZQ4cVX6cTIYpz0cllxWcdEdHRwyIPR3Eb5JC nvGWKV6Py55ypDo24enhvfq5NpAumX292HrU_pVX7TNoj2pAO_v7k0fz9bQezoNhjpPxaTOm_kzN pukc1gJzHcK6YL1riuVW6kCpyTSB4B55hYoMjJjdqV3EgrYZyr0_6cvm80JkxREF0VM3Lkrs4MpP XHiy8C2ZjUZvr8xq3g8dFK316jtCJTlM7WyLI0W4dVX4xnwdzrXp77Hx8P9hOjcGefzGmfN.9Q_s zj07Ps7oFV5We4boIWj1T_rQWFIU5Uqt5gQEVWFIv8 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ir2.yahoo.com with HTTP; Mon, 9 Sep 2019 19:29:47 +0000 Original-Received: by smtp412.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID dcfc0be591eaad6a19d6257748a3905d; Mon, 09 Sep 2019 19:29:43 +0000 (UTC) Content-Disposition: inline In-Reply-To: <83d0g92vgs.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 77.238.176.206 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:239964 Archived-At: On Mon, Sep 09, 2019 at 09:08:51PM +0300, Eli Zaretskii wrote: >> Date: Mon, 9 Sep 2019 19:08:58 +0200 >> From: Ergus >> Cc: martin rudalics , emacs-devel@gnu.org >> >> 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. > >I don't think I agree. Given the complexity of the face-related >functionalities -- face remapping, the need to recompute all the faces >when some basic face changes, the various sources of face-related >information for each buffer/string position, etc. -- I find the design >and implementation of face code quite elegant and easy to understand, >maintain and change. > I am talking about efficiency. >> 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). > >I don't think I see the optimization opportunity you are talking about >here. If you want to make a produce_glyphs method available as a TTY >hook, then why do you think it will make any tangible change of code >efficiency? It's just a dereference and a call through a function >pointer vs a test and a direct call. > This won't be an important optimization. It is just not standard. If there is no difference why are there different methods to select with if/else? The macro simply looks like a workaround. In any case, if the it/frame/rif structs are standard; then they should be always initialized. the tests will go away. And we could add an assert to test only in debug code. >> 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. > >All of this is necessary to support the immense flexibility of face-related >functionality we have, starting from the half a dozen different ways >Lisp can specify a face. There's nothing redundant in that code, >AFAIK, and unlike you, I don't find it too complicated at all. > To add one field to the faces it required many modifications. Most of them with very similar changes here and there; else if and similar changes... every time I see an if-else-if with more than 3-4 conditions I start wondering. >> 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. > >What can I say? code should be correct first, and fast only after >that. If the functionality we want to support disables some >optimizations, so be it. And I wouldn't worry about this particular >part of display code anyway, because the most expensive parts of >redisplay are elsewhere. It should be clear from a simple >consideration: the number of face changes in a typical window is an >order of magnitude or more smaller than the number of characters and >other display elements in that window. So if we want to optimize >redisplay, we should look at the 90% part of the code, not at the 10%. > Agree. But then why when the GC fails the lagging is so intense? I thought that the main part of the display engine related with GC was the faces part. >> But also a big part of the code is needed just because the >> divergence between the tui and the gui code... > >I don't think I follow. There's no difference between TTY and GUI >frames wrt face handling, except where TTY color translation is >involved. > >> if we unify the interfaces; then an important part of the >> code will be simplified and reduced and easier to maintain and modify. > >Which interfaces would you like to unify? I don't think I understand. > Most of the code conditioned with: if (FRAME_WINDOW_P (f)) could be simplified. But I understand that this could be a lot of work and I don't know enough about this.