bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

[Dmitry Gutov]

[-- Attachment #1: Type: text/plain, Size: 1674 bytes --]

It happens with different overlays, and with the default monospaced font
of my system (Ubuntu GNU/Linux), but it's easiest to reproduce doing
isearch, and using Fira Mono (TrueType version, available from
https://www.mozilla.org/en-US/styleguide/products/firefox-os/typeface/,
see the bottom of the page). Steps from emacs -Q:

1. Evaluate (run-at-time nil 0.01 'ignore)

2. Evaluate (set-face-attribute 'default nil :height 105 :family "Fira Mono")

This is optional, but with the default font the flickering is harder to
reproduce.

3. Open a text file press C-s (or C-r), enter some letters, preferably
common to that file, press C-s or C-r again. Repeat multiple times.
Maybe do that for a couple of minutes, even.

4. Observe flickering letters, usually one to the left, or one to the
right of the cursor.

Most of the time the flickering happens 2 or 3 times and stops, but I've
managed to record a couple of semi-stable loops of this on video, see
the attachment. It demonstrates a somewhat extreme situation, usually I
only see flickering once every handful searches or so.

This is in no way limited to isearch. For example, I can also see it
when typing, when using the fancy highlight-tail-mode
(http://www.emacswiki.org/emacs-en/highlight-tail.el), at least with
settings highlight-tail-steps 14, highlight-tail-timer 0.02.

Let me know if the video format (h264) is not acceptable.

In GNU Emacs 24.3.50.5 (x86_64-unknown-linux-gnu, GTK+ Version 3.8.6)
 of 2014-02-01 on axl
Repository revision: 116234 dgutov@yandex.ru-20140201170608-2rn2phrkukqt84gm
Windowing system distributor `The X.Org Foundation', version 11.0.11405000
System Description:	Ubuntu 13.10


[-- Attachment #2: screencast --]
[-- Type: video/mp4, Size: 651543 bytes --]

bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

[Stefan Monnier]

> It happens with different overlays, and with the default monospaced font
> of my system (Ubuntu GNU/Linux), but it's easiest to reproduce doing
> isearch, and using Fira Mono (TrueType version, available from

Can you also reproduce it without blink-cursor?


        Stefan

bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

[Dmitry Gutov]

On 02.02.2014 04:33, Stefan Monnier wrote:
> Can you also reproduce it without blink-cursor?

Yes, just as easily.

Normally, I have blink-cursor-mode disabled (and so I wouldn't have 
noticed the problem at all).

bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 02 Feb 2014 03:01:26 +0200
> 
> It happens with different overlays, and with the default monospaced font

I don't think this is related to overlays, not directly anyway.

> of my system (Ubuntu GNU/Linux), but it's easiest to reproduce doing
> isearch, and using Fira Mono (TrueType version, available from
> https://www.mozilla.org/en-US/styleguide/products/firefox-os/typeface/,
> see the bottom of the page). Steps from emacs -Q:
> 
> 1. Evaluate (run-at-time nil 0.01 'ignore)
> 
> 2. Evaluate (set-face-attribute 'default nil :height 105 :family "Fira Mono")
> 
> This is optional, but with the default font the flickering is harder to
> reproduce.
> 
> 3. Open a text file press C-s (or C-r), enter some letters, preferably
> common to that file, press C-s or C-r again. Repeat multiple times.
> Maybe do that for a couple of minutes, even.
> 
> 4. Observe flickering letters, usually one to the left, or one to the
> right of the cursor.
> 
> Most of the time the flickering happens 2 or 3 times and stops

No, it doesn't stop, at least not with the above recipe.  To see that,
type "M-x trace-redisplay RET" while running the above experiment --
on my system, this causes the flickering to become much more prominent
and never stop, until I exit isearch and type some simple command,
like C-f, afterwards (to remove the echo-area message).

I'm guessing that the apparent cease of the flickering is actually due
to the fact that the timer frequency is an integral multiple of the
hardware screen update rate (but I didn't pursue this line of
investigation, as I don't think it is of interest).

> This is in no way limited to isearch. For example, I can also see it
> when typing, when using the fancy highlight-tail-mode
> (http://www.emacswiki.org/emacs-en/highlight-tail.el), at least with
> settings highlight-tail-steps 14, highlight-tail-timer 0.02.

What you see is result of redrawing the cursor at a very high
frequency.  Normally, redrawing the cursor would only flicker the
character below the cursor, but with some fonts, the adjacent
characters are also affected, if the character under the cursor
"overhangs" to the left and/or to the right into the neighboring
character cells -- then Emacs redraws those adjacent characters as
well.

Why is the cursor redrawn with such a high frequency, you ask?
Because of the timer that expires every 10 msec.  When some timer
expires, Emacs always triggers redisplay.  If it didn't, features like
highlight-tail could not produce their effect.

When a timer expires and triggers redisplay, and nothing have changed
on display, Emacs normally sees that, and doesn't update the screen.
But if there is an echo-area message, like the one displayed by
isearch, this optimization is disabled, and we redisplay the echo
area.  Redisplaying the echo area involves calling the frame update
function, which redraws the cursor.  And that is what you see in the
isearch case.

With highlight-tail-mode, I see flickering only when I type text.
This is expected, since typing text modifies the color of the overlays
at a very high frequency (50 Hz with your customizations), which again
requires redrawing the current line and the cursor.  If you see
something else with highlight-tail-mode, please describe the recipe.

All of the above is quite normal, so I don't see where there would be
a bug.  Granted, Emacs 24.3 and Emacs 23 behave the same.

Thanks.

bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

[Stefan Monnier]

> But if there is an echo-area message, like the one displayed by
> isearch, this optimization is disabled, and we redisplay the echo
> area.

I guess that could be counted as a bug.


        Stefan

bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  16621@debbugs.gnu.org
> Date: Sun, 02 Feb 2014 21:12:20 -0500
> 
> > But if there is an echo-area message, like the one displayed by
> > isearch, this optimization is disabled, and we redisplay the echo
> > area.
> 
> I guess that could be counted as a bug.

Maybe, maybe not: remember all the stuff with restoring previous echo
area message and its clearing.  And good luck unlocking the logic that
implements that.  E.g., this (relevant to the issue you raised):

    /* Normally the message* functions will have already displayed and
       updated the echo area, but the frame may have been trashed, or
       the update may have been preempted, so display the echo area
       again here.  Checking message_cleared_p captures the case that
       the echo area should be cleared.  */
    if ((!NILP (echo_area_buffer[0]) && !display_last_displayed_message_p)
	|| (!NILP (echo_area_buffer[1]) && display_last_displayed_message_p)
	|| (message_cleared_p
	    && minibuf_level == 0
	    /* If the mini-window is currently selected, this means the
	       echo-area doesn't show through.  */
	    && !MINI_WINDOW_P (XWINDOW (selected_window))))
      {
	int window_height_changed_p = echo_area_display (0);

	if (message_cleared_p)
	  update_miniwindow_p = true;

	must_finish = 1;

	/* If we don't display the current message, don't clear the
	   message_cleared_p flag, because, if we did, we wouldn't clear
	   the echo area in the next redisplay which doesn't preserve
	   the echo area.  */
	if (!display_last_displayed_message_p)
	  message_cleared_p = 0;

See also redisplay_preserve_echo_area.

In any case, I'm not sure that even if we somehow succeed in
optimizing echo-area display, it would solve the problem with
flickering.  There are any number of reasons why Emacs could decide it
needs to call update_frame at the end of a redisplay cycle; the
conditions needed to avoid that are quite a few and difficult to
satisfy, unless nothing, absolutely nothing happens since the last
redisplay.

IMO, we should look in a different area of the code.  Specifically,
any time we call update_frame, the cursor will be redrawn.  Therefore,
if we want to make such frequent redisplays less visually annoying, we
need to analyze why the GUI cursor needs to be redrawn every time a
frame is updated.  This requires at least some X expert to see what
are the conditions that require the cursor to be redrawn; to my
non-expert opinion, if we didn't update anything in the vicinity of
the cursor, there should be no need to redraw it.  We don't move the
cursor to where we write glyphs, like we do on a TTY, do we?

bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

[Stefan Monnier]

> Maybe, maybe not: remember all the stuff with restoring previous echo
> area message and its clearing.  And good luck unlocking the logic that
> implements that.  E.g., this (relevant to the issue you raised):

I know it's a terrible mess.

> conditions needed to avoid that are quite a few and difficult to
> satisfy, unless nothing, absolutely nothing happens since the last
> redisplay.

But in the current case at hand, "absolutely nothing" happened.

> frame is updated.  This requires at least some X expert to see what
> are the conditions that require the cursor to be redrawn; to my
> non-expert opinion, if we didn't update anything in the vicinity of
> the cursor, there should be no need to redraw it.

Yes, that, too.

> We don't move the cursor to where we write glyphs, like we do on
> a TTY, do we?

Of course we don't.


        Stefan

bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: dgutov@yandex.ru,  16621@debbugs.gnu.org
> Date: Mon, 03 Feb 2014 08:41:57 -0500
> 
> > conditions needed to avoid that are quite a few and difficult to
> > satisfy, unless nothing, absolutely nothing happens since the last
> > redisplay.
> 
> But in the current case at hand, "absolutely nothing" happened.

Something did happen (in the isearch recipe): we've redisplayed the
echo area.

bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

[Dmitry Gutov]

On 02.02.2014 18:39, Eli Zaretskii wrote:
> I don't think this is related to overlays, not directly anyway.

True, I've seen it without overlays, too, recently.

> No, it doesn't stop, at least not with the above recipe.  To see that,
> type "M-x trace-redisplay RET" while running the above experiment --
> on my system, this causes the flickering to become much more prominent
> and never stop, until I exit isearch and type some simple command,
> like C-f, afterwards (to remove the echo-area message).

I wanted to say there's no such function, but apparently one has to 
compile Emacs with -DGLYPH_DEBUG to use it. I'll take your word for it.

> What you see is result of redrawing the cursor at a very high
> frequency.  Normally, redrawing the cursor would only flicker the
> character below the cursor, but with some fonts, the adjacent
> characters are also affected, if the character under the cursor
> "overhangs" to the left and/or to the right into the neighboring
> character cells -- then Emacs redraws those adjacent characters as
> well.

Isn't the fact that flickering is at all possible in this scenario, a 
problem? Doesn't it mean that occasional flickers can still happen under 
normal conditions (timers with much longer intervals, for example),just 
that the probability of occurrence is smaller. If I understand you 
right, all it takes is for timer to fire at just the right moment before 
the screen updates.

> Why is the cursor redrawn with such a high frequency, you ask?
> Because of the timer that expires every 10 msec.  When some timer
> expires, Emacs always triggers redisplay.  If it didn't, features like
> highlight-tail could not produce their effect.

Thank you, I guess that solves the immediate problem with 
highlight-tail-mode for me (lower the amount of steps, increase the 
intervals), but one of the reasons I filed this bug is I've been 
noticing occasional redisplay flickers with Emacs for as long as I can 
remember. They are a nuisance, and until now they've been impossible to 
reproduce, for me.

> With highlight-tail-mode, I see flickering only when I type text.
> This is expected, since typing text modifies the color of the overlays
> at a very high frequency (50 Hz with your customizations), which again
> requires redrawing the current line and the cursor.  If you see
> something else with highlight-tail-mode, please describe the recipe.

I do see similar flickering from time to time after I stop typing, but 
that can be chalked up to timers too, I guess. This is also harder to 
reproduce (happens not often, and in longer-living Emacs sessions).

> All of the above is quite normal, so I don't see where there would be
> a bug.  Granted, Emacs 24.3 and Emacs 23 behave the same.

Some relatively low-hanging fruit has already been mentioned in the 
comments, but would it be too much to expect some sort of 
double-buffering used for Emacs display, eventually? Or is the related 
overhead considered too much of a cost?

bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

[Stefan Monnier]

>> But in the current case at hand, "absolutely nothing" happened.
> Something did happen (in the isearch recipe): we've redisplayed the
> echo area.

But nothing "absolutely nothing happened" to the window where the
text flickers.  And even the "redisplayed echo area" itself was done
despite the fact that "absolutely nothing" happened (between the end of
the previous redisplay and the beginning of the next).


        Stefan

bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: dgutov@yandex.ru,  16621@debbugs.gnu.org
> Date: Mon, 03 Feb 2014 22:28:43 -0500
> 
> >> But in the current case at hand, "absolutely nothing" happened.
> > Something did happen (in the isearch recipe): we've redisplayed the
> > echo area.
> 
> But nothing "absolutely nothing happened" to the window where the
> text flickers.

That's the issue with redrawing the cursor that I mentioned.  If we
can find a way to avoid that, we will probably solve most of the
problem, if not all of it.

> And even the "redisplayed echo area" itself was done despite the
> fact that "absolutely nothing" happened (between the end of the
> previous redisplay and the beginning of the next).

Yes, but there could be some message "shown through", like from an
input method or GC or whatever.  That's why echo area is redisplayed
when it is active, I guess.

bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

[Eli Zaretskii]

> Date: Tue, 04 Feb 2014 04:34:58 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 16621@debbugs.gnu.org, Stefan Monnier <monnier@IRO.UMontreal.CA>
> 
> Isn't the fact that flickering is at all possible in this scenario, a 
> problem?

Yes, but it is currently an unavoidable one, because this is how the
code was designed and implemented to work.

> Doesn't it mean that occasional flickers can still happen under 
> normal conditions (timers with much longer intervals, for example),just 
> that the probability of occurrence is smaller. If I understand you 
> right, all it takes is for timer to fire at just the right moment before 
> the screen updates.

Indeed, that's true.

> Some relatively low-hanging fruit has already been mentioned in the 
> comments

Like what?  If you mean the fact that we redraw the cursor when
perhaps that could be avoided, someone else will have to suggest a
better algorithm than doing it on every frame update.  Nothing else
discussed here was easy, either.

> but would it be too much to expect some sort of double-buffering
> used for Emacs display, eventually?

You mean, outside Emacs?  Yes, probably, but then this isn't an Emacs
issue, and I know absolutely nothing about it.

> Or is the related overhead considered too much of a cost?

If you mean double buffering inside Emacs, you will have to explain
why you think it will solve the problem.

bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

[Dmitry Gutov]

On 04.02.2014 05:48, Eli Zaretskii wrote:
>> Some relatively low-hanging fruit has already been mentioned in the
>> comments
>
> Like what?  If you mean the fact that we redraw the cursor when
> perhaps that could be avoided, someone else will have to suggest a
> better algorithm than doing it on every frame update.

No suggestions from me here.

It should still be easier than double buffering, though.

>> but would it be too much to expect some sort of double-buffering
>> used for Emacs display, eventually?
>
> You mean, outside Emacs?  Yes, probably, but then this isn't an Emacs
> issue, and I know absolutely nothing about it.

Would a windowing system know which Emacs display states are 
"consistent", and which aren't?

>> Or is the related overhead considered too much of a cost?
>
> If you mean double buffering inside Emacs, you will have to explain
> why you think it will solve the problem.

AFAIU, flickering happens when the screen refreshes while Emacs display 
is in an inconsistent state. Like, you've cleared a rectangle to paint a 
character in it, but haven't yet painted it

If you copied the rendered state into a buffer, then cleared and painted 
the character there, then rendered the buffer into the window as a 
whole, the windowing system won't get a chance to see and display the 
intermediate state.

bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

[Eli Zaretskii]

> Date: Tue, 04 Feb 2014 08:17:38 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 16621@debbugs.gnu.org, monnier@IRO.UMontreal.CA
> 
> > You mean, outside Emacs?  Yes, probably, but then this isn't an Emacs
> > issue, and I know absolutely nothing about it.
> 
> Would a windowing system know which Emacs display states are 
> "consistent", and which aren't?

If hints are needed, we could do that.

> AFAIU, flickering happens when the screen refreshes while Emacs display 
> is in an inconsistent state. Like, you've cleared a rectangle to paint a 
> character in it, but haven't yet painted it
> 
> If you copied the rendered state into a buffer, then cleared and painted 
> the character there, then rendered the buffer into the window as a 
> whole, the windowing system won't get a chance to see and display the 
> intermediate state.

Avoiding the cursor redraws sounds much easier, but again, I'm not an
expert on this.  Perhaps Jan could comment.

bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

[Jan D.]

Hi.

4 feb 2014 kl. 17:00 skrev Eli Zaretskii <eliz@gnu.org>:

>> Date: Tue, 04 Feb 2014 08:17:38 +0200
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> CC: 16621@debbugs.gnu.org, monnier@IRO.UMontreal.CA
>> 
>>> You mean, outside Emacs?  Yes, probably, but then this isn't an Emacs
>>> issue, and I know absolutely nothing about it.
>> 
>> Would a windowing system know which Emacs display states are 
>> "consistent", and which aren't?
> 
> If hints are needed, we could do that.
> 
>> AFAIU, flickering happens when the screen refreshes while Emacs display 
>> is in an inconsistent state. Like, you've cleared a rectangle to paint a 
>> character in it, but haven't yet painted it
>> 
>> If you copied the rendered state into a buffer, then cleared and painted 
>> the character there, then rendered the buffer into the window as a 
>> whole, the windowing system won't get a chance to see and display the 
>> intermediate state.
> 
> Avoiding the cursor redraws sounds much easier, but again, I'm not an
> expert on this.  Perhaps Jan could comment.

Avoiding the cursor redraws must be easier.  Implementing double buffering is more work.
Not rocket sience, but it would probably take a while to get it right. 

Ironically we turn off the Gtk double buffering, because it only works with Gtk drawing functions,
and Emacs uses X functions.  A more long term solution would be to use Cairo.  There is a patch
for it, but it does not work on the trunk.  Mainly because the ftfont backend is broken.

So, if there is a way to avoid cursor redraws, go for it.  All ports benefit.  Double buffering is a port specific solution, unless the display engine does double buffering by having two sets of glyphs and compares them to see what has really changed. Sounds like a big project.

       Jan D.

bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

[Eli Zaretskii]

> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Tue, 4 Feb 2014 23:08:13 +0100
> Cc: Dmitry Gutov <dgutov@yandex.ru>,
>  "16621@debbugs.gnu.org" <16621@debbugs.gnu.org>,
>  "monnier@IRO.UMontreal.CA" <monnier@IRO.UMontreal.CA>
> 
> So, if there is a way to avoid cursor redraws, go for it.

Can you tell when does the cursor need to be redrawn on X?

> Double buffering is a port specific solution, unless the display engine does double buffering by having two sets of glyphs and compares them to see what has really changed. Sounds like a big project.

We do have 2 sets of glyphs, but they are not guaranteed to be
complete: we only care about the portions of display that changed, so
the parts that we know didn't change we don't bother updating.

bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

[Jan Djärv]

Hi.

5 feb 2014 kl. 04:57 skrev Eli Zaretskii <eliz@gnu.org>:

>> From: "Jan D." <jan.h.d@swipnet.se>
>> Date: Tue, 4 Feb 2014 23:08:13 +0100
>> Cc: Dmitry Gutov <dgutov@yandex.ru>,
>> "16621@debbugs.gnu.org" <16621@debbugs.gnu.org>,
>> "monnier@IRO.UMontreal.CA" <monnier@IRO.UMontreal.CA>
>> 
>> So, if there is a way to avoid cursor redraws, go for it.
> 
> Can you tell when does the cursor need to be redrawn on X?

Not sure what you mean, but when it blinks, when text under it (or near it due to overhangs) changes, or when there is an expose event.

	Jan D.

bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

[Stefan Monnier]

>> So, if there is a way to avoid cursor redraws, go for it.
> Can you tell when does the cursor need to be redrawn on X?

The problem in the current case is that the window hasn't had any
modification at all, so we shouldn't even try to redraw any part of it.
Methinks there's a bit of code somewhere which maybe sets the `redisplay'
bit unnecessarily.


        Stefan

bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Wed, 5 Feb 2014 07:02:22 +0100
> Cc: Dmitry Gutov <dgutov@yandex.ru>,
>  16621@debbugs.gnu.org,
>  monnier@IRO.UMontreal.CA
> 
> > Can you tell when does the cursor need to be redrawn on X?
> 
> Not sure what you mean, but when it blinks, when text under it (or near it due to overhangs) changes, or when there is an expose event.

That's exactly what I was asking, thanks.

bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: "Jan D." <jan.h.d@swipnet.se>,  dgutov@yandex.ru,  16621@debbugs.gnu.org
> Date: Wed, 05 Feb 2014 08:46:17 -0500
> 
> >> So, if there is a way to avoid cursor redraws, go for it.
> > Can you tell when does the cursor need to be redrawn on X?
> 
> The problem in the current case is that the window hasn't had any
> modification at all, so we shouldn't even try to redraw any part of it.

The window is indeed not redrawn, only its cursor is.

We currently lack infrastructure that would allow us to notice that
the screen line where the cursor is displayed did not change.  So we
cannot decide not to redraw the cursor.

> Methinks there's a bit of code somewhere which maybe sets the `redisplay'
> bit unnecessarily.

I thought I explained a few messages back what "flag" is that: the
moment we redisplay the echo area, we are forced to call update_frame,
for the selected frame, which will redraw the cursors of that frame's
windows (and also its fringes, btw).

bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

[Stefan Monnier]

> I thought I explained a few messages back what "flag" is that: the
> moment we redisplay the echo area, we are forced to call update_frame,
> for the selected frame, which will redraw the cursors of that frame's
> windows (and also its fringes, btw).

We can probably refine update_frame then, so it only redraws the windows
that have changed, which can be recognized thanks to a flag such as
`redisplay' or a new flag if that one can't be used (under ttys, the
redraw is really frame-wide so that wouldn't apply, but for GUIs that
should not be a problem).


        Stefan

bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: jan.h.d@swipnet.se,  dgutov@yandex.ru,  16621@debbugs.gnu.org
> Date: Wed, 05 Feb 2014 13:57:43 -0500
> 
> > I thought I explained a few messages back what "flag" is that: the
> > moment we redisplay the echo area, we are forced to call update_frame,
> > for the selected frame, which will redraw the cursors of that frame's
> > windows (and also its fringes, btw).
> 
> We can probably refine update_frame then, so it only redraws the windows
> that have changed, which can be recognized thanks to a flag such as
> `redisplay' or a new flag if that one can't be used (under ttys, the
> redraw is really frame-wide so that wouldn't apply, but for GUIs that
> should not be a problem).

This is not needed, because update_frame actually does nothing in this
case: it sees that none of the lines in any window on the selected
frame changed, and does not redraw any of their screen lines.  But it
always redraws the cursor and the fringes.  So we only need to
introduce some infrastructure that would allow us to avoid redrawing
the cursor on GUI frames, when the text surrounding the cursor was not
redrawn.

bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

[Stefan Monnier]

> So we only need to introduce some infrastructure that would allow us
> to avoid redrawing the cursor on GUI frames, when the text surrounding
> the cursor was not redrawn.

Right.  But if the `redisplay' bit wasn't set, then we shouldn't even
need to look at any part of the window/buffer to decide that there's
nothing to do.


        Stefan

bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: jan.h.d@swipnet.se,  dgutov@yandex.ru,  16621@debbugs.gnu.org
> Date: Wed, 05 Feb 2014 16:46:14 -0500
> 
> > So we only need to introduce some infrastructure that would allow us
> > to avoid redrawing the cursor on GUI frames, when the text surrounding
> > the cursor was not redrawn.
> 
> Right.  But if the `redisplay' bit wasn't set, then we shouldn't even
> need to look at any part of the window/buffer to decide that there's
> nothing to do.

There are 2 phases to redisplay.  The 'redisplay' flag is consulted in
the first phase, where we decide whether anything at all might need to
be redrawn, and if so, construct the "desired" glyph matrices for each
window that might need it.  The second phase, which is entered from
update_frame or update_window, compares the "desired" matrices with
the "current" ones, and actually redraws the changed portions of the
display, if any.  This second phase knows nothing about the flags you
mention, and doesn't need to, because it already refrains from
displaying the screen portions which didn't change.

bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

[Stefan Monnier]

> window that might need it.  The second phase, which is entered from
> update_frame or update_window, compares the "desired" matrices with
> the "current" ones, and actually redraws the changed portions of the
> display, if any.  This second phase knows nothing about the flags you
> mention, and doesn't need to, because it already refrains from
> displaying the screen portions which didn't change.

IIUC it does know a bit about it, in that only frames which had
a redisplay bit set somewhere are passed to update_frame (at least that
was the intention).


        Stefan

bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: jan.h.d@swipnet.se,  dgutov@yandex.ru,  16621@debbugs.gnu.org
> Date: Thu, 06 Feb 2014 08:08:08 -0500
> 
> > window that might need it.  The second phase, which is entered from
> > update_frame or update_window, compares the "desired" matrices with
> > the "current" ones, and actually redraws the changed portions of the
> > display, if any.  This second phase knows nothing about the flags you
> > mention, and doesn't need to, because it already refrains from
> > displaying the screen portions which didn't change.
> 
> IIUC it does know a bit about it, in that only frames which had
> a redisplay bit set somewhere are passed to update_frame (at least that
> was the intention).

Maybe I'm blind, but I don't see that.  In any case, the selected
frame seems to be updated regardless, if only we come to the 'update'
label in redisplay_internal.  We can avoid that label, but not when
echo-area display is active.