unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] master 5c9304e: Disable some display optimizations when frames need redisplay
Date: Sat, 03 Oct 2015 10:21:18 +0300	[thread overview]
Message-ID: <83r3lc4du9.fsf@gnu.org> (raw)
In-Reply-To: <jwvmvw0eqcr.fsf-monnier+emacsdiffs@gnu.org>

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> 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?



  reply	other threads:[~2015-10-03  7:21 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 [this message]
2015-10-04  2:33                   ` Stefan Monnier
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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=83r3lc4du9.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).