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, 02 Sep 2019 19:18:19 +0300 Message-ID: <83zhjm7juc.fsf@gnu.org> 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> <20190902110504.zniyfmd7bi53iyxe@Ergus> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="79527"; 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 02 18:19:12 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 1i4p2p-000KEv-On for ged-emacs-devel@m.gmane.org; Mon, 02 Sep 2019 18:19:07 +0200 Original-Received: from localhost ([::1]:38204 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i4p2j-00032U-Fo for ged-emacs-devel@m.gmane.org; Mon, 02 Sep 2019 12:19:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49219) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i4p2E-0002zh-Ma for emacs-devel@gnu.org; Mon, 02 Sep 2019 12:18:32 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37807) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i4p2E-0004PY-3C; Mon, 02 Sep 2019 12:18:30 -0400 Original-Received: from [176.228.60.248] (port=2976 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1i4p2D-0007Qw-EO; Mon, 02 Sep 2019 12:18:29 -0400 In-reply-to: <20190902110504.zniyfmd7bi53iyxe@Ergus> (message from Ergus on Mon, 2 Sep 2019 13:05:04 +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:239778 Archived-At: > 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).