From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Question about display engine Date: Mon, 09 Sep 2019 21:08:51 +0300 Message-ID: <83d0g92vgs.fsf@gnu.org> 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> <20190909170826.w3ug6iv3fnrxh4jp@Ergus> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="51029"; mail-complaints-to="usenet@blaine.gmane.org" Cc: rudalics@gmx.at, emacs-devel@gnu.org To: Ergus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 09 20:10:03 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 1i7O71-000DBO-6O for ged-emacs-devel@m.gmane.org; Mon, 09 Sep 2019 20:10:03 +0200 Original-Received: from localhost ([::1]:59836 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i7O70-0000w5-1M for ged-emacs-devel@m.gmane.org; Mon, 09 Sep 2019 14:10:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56286) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i7O5o-0008Mw-9h for emacs-devel@gnu.org; Mon, 09 Sep 2019 14:08:49 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40110) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i7O5n-0005B3-GW; Mon, 09 Sep 2019 14:08:47 -0400 Original-Received: from [176.228.60.248] (port=4294 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1i7O5m-000754-Db; Mon, 09 Sep 2019 14:08:47 -0400 In-reply-to: <20190909170826.w3ug6iv3fnrxh4jp@Ergus> (message from Ergus on Mon, 9 Sep 2019 19:08:58 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:239960 Archived-At: > 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. > 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. > 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. > 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%. > 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.