bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-upda


From: Eli Zaretskii
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Date: Sun, 16 Jul 2023 17:27:41 +0300

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  64596@debbugs.gnu.org
> Date: Sun, 16 Jul 2023 10:04:30 -0400
> 
> >> -  /* True means redisplay has to consider all windows on all
> >> -     frames.  False, only selected_window is considered.  */
> >> +  /* False, means that only the selected_window needs to be updated.
> >> +     True means that other windows may need to be updated as well,
> >> +     so we need to consult the `redisplay` bits of
> >> +     all windows/buffer/frames.  */
> >>    bool consider_all_windows_p;
> >
> > BTW, is there any particular reason why windows_or_buffers_changed is
> > not a queue of windows/buffer to be re-displayed?
> 
> FWIW, I suspect that the loop over all windows is always
> insignificant, so (in theory) we could get rid of the optimization that
> looks only at the selected window in most cases and we wouldn't notice
> any slowdown or measurable increase in CPU use.

True, but with one caveat: the loop over all windows will not
trivially return from redisplay_window if the window's frame has its
redisplay flag set.  So it is enough for the frame to have this flag
set, for redisplay to have to consider all of its windows, even if the
redisplay flag of each and every one of that frame's windows is reset.
And once we decided not to return immediately after entering
redisplay_window, the processing is not insignificant, since it
involves making the window's buffer the current one, and as result
setting all the values of buffer-local variables.

So it sounds like we should make sure we don't set the frame's
redisplay flag unless most or all of its windows actually need to be
considered.  Is this so with the current code?

> So, replacing the `redisplay` bits with a queue is probably not a great
> idea (especially since setting a bit is much faster than adding an
> element to a queue where you need to try and avoid adding the same
> element a hundred times).

Agreed.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]