all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] master 5c9304e: Disable some display optimizations when frames need redisplay
Date: Sat, 03 Oct 2015 22:33:06 -0400	[thread overview]
Message-ID: <jwvbncfv07e.fsf-monnier+emacsdiffs@gnu.org> (raw)
In-Reply-To: <83r3lc4du9.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 03 Oct 2015 10:21:18 +0300")

> 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?

How do you like the patch below?


        Stefan


diff --git a/src/xdisp.c b/src/xdisp.c
index 1524783..439d9cb 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -434,22 +434,47 @@ static Lisp_Object Vmessage_stack;
 
 static bool message_enable_multibyte;
 
-/* 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).  */
+/* At each redisplay cycle, we should refresh everything there is to refresh.
+   To do that efficiently, we use many optimizations that try to make sure we
+   don't waste too much time updating things that haven't changed.
+   The coarsest such optimization is that, in the most common cases, we only
+   look at the selected-window.
+
+   To know whether other windows should be considered for redisplay, we use the
+   variable windows_or_buffers_changed: as long as it is 0, it means that we
+   have not noticed anything that should require updating anything else than
+   the selected-window.  If it is set to REDISPLAY_SOME, it means that since
+   last redisplay, some changes have been made which could impact other
+   windows.  To know which ones need redisplay, every buffer, window, and frame
+   has a `redisplay' bit, which (if true) means that this object needs to be
+   redisplayed.  If windows_or_buffers_changed is 0, we know there's no point
+   looking for those `redisplay' bits (actually, there might be some such bits
+   set, but then only on objects which aren't displayed anyway).
+
+   Mostly for historical reasons, windows_or_buffers_changed can also take
+   other non-zero values.  In that case, the precise value doesn't matter (it
+   encodes the cause of the setting but is only used for debugging purposes),
+   and what it means is that we shouldn't pay attention to any `redisplay' bits
+   and we should simply try and redisplay every since window out there.  */
 
-int update_mode_lines;
+int windows_or_buffers_changed;
 
-/* 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).  */
+/* Nonzero if we should redraw the mode lines on the next redisplay.
+   Similarly to `windows_or_buffers_changed', If it has value REDISPLAY_SOME,
+   then only redisplay the mode lines in those buffers/windows/frames where the
+   `redisplay' bit has been set.
+   For any other value, redisplay all mode lines (the number used is then only
+   used to track down the cause for this full-redisplay).
+
+   The `redisplay' bits are the same as those used for
+   windows_or_buffers_changed, and setting windows_or_buffers_changed also
+   causes recomputation of the mode lines of all those windows.  IOW this
+   variable only has an effect if windows_or_buffers_changed is zero, in which
+   case we should only need to redisplay the mode-line of those objects with
+   a `redisplay' bit set but not the window's text content (tho we may still
+   need to refresh the text content of the selected-window).  */
 
-int windows_or_buffers_changed;
+int update_mode_lines;
 
 /* True after display_mode_line if %l was used and it displayed a
    line number.  */



  reply	other threads:[~2015-10-04  2:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20150930193450.11644.62040@vcs.savannah.gnu.org>
     [not found] ` <E1ZhN9O-00032Q-5G@vcs.savannah.gnu.org>
2015-10-02 12:44   ` [Emacs-diffs] master 5c9304e: Disable some display optimizations when frames need redisplay Stefan Monnier
2015-10-02 13:40     ` Eli Zaretskii
2015-10-02 15:46       ` Stefan Monnier
2015-10-02 17:49         ` Eli Zaretskii
2015-10-02 20:55           ` Stefan Monnier
2015-10-02 21:24             ` Eli Zaretskii
2015-10-03  1:05               ` Stefan Monnier
2015-10-03  7:21                 ` Eli Zaretskii
2015-10-04  2:33                   ` Stefan Monnier [this message]
2015-10-04  9:53                     ` Eli Zaretskii
2015-10-05 15:50                       ` Stefan Monnier
2015-10-05 16:57                         ` Eli Zaretskii
2015-10-05 22:46                           ` Stefan Monnier
2015-10-06  1:19                             ` Stefan Monnier
2015-10-06  7:57                             ` martin rudalics
2015-10-06 16:15                               ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvbncfv07e.fsf-monnier+emacsdiffs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.