From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 5c9304e: Disable some display optimizations when frames need redisplay Date: Sat, 03 Oct 2015 10:21:18 +0300 Message-ID: <83r3lc4du9.fsf@gnu.org> References: <20150930193450.11644.62040@vcs.savannah.gnu.org> <831tdd75i3.fsf@gnu.org> <83eghd5ff2.fsf@gnu.org> <83vbap3qxb.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1443856914 31192 80.91.229.3 (3 Oct 2015 07:21:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 3 Oct 2015 07:21:54 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 03 09:21:39 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZiH8Q-0005nY-EZ for ged-emacs-devel@m.gmane.org; Sat, 03 Oct 2015 09:21:34 +0200 Original-Received: from localhost ([::1]:37283 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZiH8P-0004Iq-RC for ged-emacs-devel@m.gmane.org; Sat, 03 Oct 2015 03:21:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35926) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZiH8M-0004Ih-Qz for emacs-devel@gnu.org; Sat, 03 Oct 2015 03:21:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZiH8H-0004U2-Ll for emacs-devel@gnu.org; Sat, 03 Oct 2015 03:21:30 -0400 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:51570) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZiH8H-0004Tq-93 for emacs-devel@gnu.org; Sat, 03 Oct 2015 03:21:25 -0400 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NVM00C00URS7D00@mtaout28.012.net.il> for emacs-devel@gnu.org; Sat, 03 Oct 2015 10:20:59 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NVM00L5YV2YZG90@mtaout28.012.net.il>; Sat, 03 Oct 2015 10:20:59 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.184 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:190772 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Fri, 02 Oct 2015 21:05:13 -0400 > > > So that special value of windows_or_buffers_changed just adds > > management (you need to reset it, and it can acquire higher values > > depending on what redisplay_internal discovers), without adding any > > value. > > I'm not sure how much there is to gain from removing it, since it's also > used for wset_redisplay and bset_redisplay. But it sounds like you have > a plan. > > > The loop over all frames checking whether any have the 'redisplay' > > flag set is fast, so there's no need for a global flag to convey that. > > Indeed, such a loop is cheap. But as long as windows_or_buffers_changed > is used for the wset_redisplay and bset_redisplay, I don't see much > benefit in removing it from fset_redisplay. > > But of course, looping over all windows is also fairly cheap, so I guess > you're planning to remove it also from wset_redisplay and bset_redisplay? Maybe, I don't know yet. I intended to, but now I think I need to digest the new knowledge first. > >> 100% agreement, and that's why I introduced those `redisplay' bits and > >> the corresponding REDISPLAY_SOME value for windows_or_buffers_changed. > >> > >> And AFAIK it already has the effect that when we call fset_redisplay only > >> those frames get redisplayed. > > > Maybe so, but the effect of this on frames is completely undocumented, > > I tried to document it in those var's comment: > > /* Nonzero if we should redraw the mode lines on the next redisplay. > If it has value REDISPLAY_SOME, then only redisplay the mode lines where > the `redisplay' bit has been set. Otherwise, redisplay all mode lines > (the number used is then only used to track down the cause for this > full-redisplay). */ > > int update_mode_lines; > > /* Nonzero if window sizes or contents other than selected-window have > changed since last redisplay that finished. > If it has value REDISPLAY_SOME, then only redisplay the windows where > the `redisplay' bit has been set. Otherwise, redisplay all windows > (the number used is then only used to track down the cause for this > full-redisplay). */ > > int windows_or_buffers_changed; > > I see it's not very specific about frame/window/buffer's `redisplay' > flag, tho. Indeed. Tell you what: if you add commentary that describes the logic of using these two variables, the window's and frame's 'redisplay' flags, and how all those are used to decide which parts need to be redisplayed, and if that commentary makes it clear that the code I added is redundant, I will remove the code I added, and see if some alternative design would be better. Deal?