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: Fri, 02 Oct 2015 21:05:13 -0400 [thread overview]
Message-ID: <jwvmvw0eqcr.fsf-monnier+emacsdiffs@gnu.org> (raw)
In-Reply-To: <83vbap3qxb.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 03 Oct 2015 00:24:00 +0300")
>> So, the value 2 (aka REDISPLAY_SOME) already gives you the information
>> that "only frames F1 and F2 need to be redisplayed".
> But you need to examine the frame's 'redisplay' flag anyway.
Which frame(s)? If windows_or_buffers_changed is 0, you shouldn't need
to examine any frame's `redisplay' flag, AFAIK.
> 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?
>> 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.
>> Also rather than "don't set windows_or_buffers_changed in
>> fset_redisplay", it seems like it would be safer to try and eliminate
>> (one by one) the places where we check the value of
>> windows_or_buffers_changed instead of checking f->redisplay or something
>> like that.
> You cannot eliminate windows_or_buffers_changed without replacing them
> with something.
I lost you here. I thought you're suggesting to get rid of this
variable. I'm only suggesting to remove (step by step) some of those
places where we check its value and I'm not suggesting to remove them
without replacing them with something, but rather I suggest to replace
those checks by checks of things like f->redisplay.
Stefan
next prev parent reply other threads:[~2015-10-03 1:05 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 [this message]
2015-10-03 7:21 ` Eli Zaretskii
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=jwvmvw0eqcr.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 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).