bug#14744: 24.3.50; Flickering mouse-face on process output

bug#14744: 24.3.50; Flickering mouse-face on process output

[Christopher Schmidt]

    emacs -q
    C-x 2
    M-x shell RET
    cat /dev/urandom RET
    C-x o
    # Move mouse on one of the buttons so the face changes to highlight

The button flickers here.

Xorg and GTK+ 2.24.10 on GNU/Linux and current Emacs trunk.  This issue
is easily reproducible on older Emacsen, such as 24.3 or 23.4.

        Christopher

bug#14744: 24.3.50; Flickering mouse-face on process output

[Eli Zaretskii]

> From: Christopher Schmidt <christopher@ch.ristopher.com>
> Date: Sat, 29 Jun 2013 01:10:51 +0100 (BST)
> 
>     emacs -q
>     C-x 2
>     M-x shell RET
>     cat /dev/urandom RET
>     C-x o
>     # Move mouse on one of the buttons so the face changes to highlight
> 
> The button flickers here.
> 
> Xorg and GTK+ 2.24.10 on GNU/Linux and current Emacs trunk.  This issue
> is easily reproducible on older Emacsen, such as 24.3 or 23.4.

Redisplay of a window always includes redisplay of the tool bar.  The
latter involves drawing the buttons, and then applying the depressed
faced to the button that the mouse pointer hovers above.  That is what
you see, I believe.  So why do you consider that a bug?

bug#14744: 24.3.50; Flickering mouse-face on process output

[Christopher Schmidt]

Eli Zaretskii <eliz@gnu.org> writes:
> Redisplay of a window always includes redisplay of the tool bar.  The
> latter involves drawing the buttons, and then applying the depressed
> faced to the button that the mouse pointer hovers above.  That is what
> you see, I believe.  So why do you consider that a bug?

I was not talking about the tool bar.  I was talking about the buttons
in the other window of Emacs, such as

    Emacs Tutorial	Learn basic keystroke commands
    ^^^^^^^^^^^^^^
    Emacs Guided Tour	Overview of Emacs features at gnu.org
    ^^^^^^^^^^^^^^^^^
    View Emacs Manual	View the Emacs manual using Info
    ^^^^^^^^^^^^^^^^^
I call them buttons because they were created using insert-button.  This
does not exactly matter here.  Any text with a mouse-face will do.

I see actual flickering.  That is, I move my mouse cursor over the text
and expect the text face to be highlight as long as the cursor is
somewhere in between the continuous fragment of text.  It is not.  The
actual face is switching between two faces, one of them being highlight.

I am able to reproduce the bug on different GNU/Linux/Xorg/GTK 2.*
boxes.  On a fast machine the flickering is barely noticeable, on a slow
one the faces flickers with a high frequency which is very distracting
and mildly annoying.

        Christopher

bug#14744: 24.3.50; Flickering mouse-face on process output

[Stephen Berman]

On Sat, 29 Jun 2013 10:47:15 +0100 (BST) Christopher Schmidt <christopher@ch.ristopher.com> wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>> Redisplay of a window always includes redisplay of the tool bar.  The
>> latter involves drawing the buttons, and then applying the depressed
>> faced to the button that the mouse pointer hovers above.  That is what
>> you see, I believe.  So why do you consider that a bug?
>
> I was not talking about the tool bar.  I was talking about the buttons
> in the other window of Emacs, such as
>
>     Emacs Tutorial	Learn basic keystroke commands
>     ^^^^^^^^^^^^^^
>     Emacs Guided Tour	Overview of Emacs features at gnu.org
>     ^^^^^^^^^^^^^^^^^
>     View Emacs Manual	View the Emacs manual using Info
>     ^^^^^^^^^^^^^^^^^
> I call them buttons because they were created using insert-button.  This
> does not exactly matter here.  Any text with a mouse-face will do.
>
> I see actual flickering.  That is, I move my mouse cursor over the text
> and expect the text face to be highlight as long as the cursor is
> somewhere in between the continuous fragment of text.  It is not.  The
> actual face is switching between two faces, one of them being highlight.

I've noticed this for a long time (I can't remember when I first noticed
it, but it was certainly many months, perhaps years ago); I think I
always see it when the *shell* buffer is rapidly outputting data from
building Emacs, and a Gnus *Summary* buffer is in the other window.

Steve Berman

bug#14744: 24.3.50; Flickering mouse-face on process output

[Eli Zaretskii]

> From: Christopher Schmidt <christopher@ch.ristopher.com>
> Date: Sat, 29 Jun 2013 10:47:15 +0100 (BST)
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > Redisplay of a window always includes redisplay of the tool bar.  The
> > latter involves drawing the buttons, and then applying the depressed
> > faced to the button that the mouse pointer hovers above.  That is what
> > you see, I believe.  So why do you consider that a bug?
> 
> I was not talking about the tool bar.  I was talking about the buttons
> in the other window of Emacs, such as
> 
>     Emacs Tutorial	Learn basic keystroke commands
>     ^^^^^^^^^^^^^^
>     Emacs Guided Tour	Overview of Emacs features at gnu.org
>     ^^^^^^^^^^^^^^^^^
>     View Emacs Manual	View the Emacs manual using Info
>     ^^^^^^^^^^^^^^^^^

That doesn't matter.  In the situation you described, Emacs redisplays
all the windows, which involves redrawing the mouse highlight of these
buttons.

> I see actual flickering.  That is, I move my mouse cursor over the text
> and expect the text face to be highlight as long as the cursor is
> somewhere in between the continuous fragment of text.  It is not.  The
> actual face is switching between two faces, one of them being highlight.

Because we redraw the window.

Redisplay optimization that refrains from redrawing windows other than
the one whose buffer and mode line get updated was never implemented.

For the record, what is the real-life use case where this matters?

bug#14744: 24.3.50; Flickering mouse-face on process output

[Christopher Schmidt]

Eli Zaretskii <eliz@gnu.org> writes:
> For the record, what is the real-life use case where this matters?

The one Stephen described in <8761wxfbm8.fsf@rosalinde.fritz.box>.

        Christopher

bug#14744: 24.3.50; Flickering mouse-face on process output

[Eli Zaretskii]

> From: Christopher Schmidt <christopher@ch.ristopher.com>
> Date: Sat, 29 Jun 2013 13:56:53 +0100 (BST)
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > For the record, what is the real-life use case where this matters?
> 
> The one Stephen described in <8761wxfbm8.fsf@rosalinde.fritz.box>.

Thanks.  For the record, here's what happens:

  . comint-output-filter moves the comint-last-prompt-overlay overlay

  . This eventually calls modify_overlay, which has this code:

     /* If BUF is visible, consider updating the display if ...  */
     if (buffer_window_count (buf) > 0)
       {
	 /* ... it's visible in other window than selected,  */
	 if (buf != XBUFFER (XWINDOW (selected_window)->contents))
	   windows_or_buffers_changed = 1;
	 /* ... or if we modify an overlay at the end of the buffer
	    and so we cannot be sure that window end is still valid.  */
	 else if (end >= ZV && start <= ZV)
	   windows_or_buffers_changed = 1;
       }

    In our case, the overlay is at the end of the buffer, so the last
    'else if' clause fires, and sets windows_or_buffers_changed to a
    non-zero value.

  . When redisplay sees a non-zero value in windows_or_buffers_changed,
    it forces a thorough redisplay of all the windows, because having
    the window end invalid generally means the window configuration
    might have changed.

I guess one way of fixing this problem would be to modify comint.el
not to use overlays for this purpose.

bug#14744: 24.3.50; Flickering mouse-face on process output

[Christopher Schmidt]

Eli Zaretskii <eliz@gnu.org> writes:
> Thanks.  For the record, here's what happens:
[...]

Thanks for the thorough explanation of what's going on.

> I guess one way of fixing this problem would be to modify comint.el
> not to use overlays for this purpose.

This works around the underlying issue.  There are other real use cases
in which, due to whatever reason, a redisplay is enforced and this
artifact appears.

        Christopher

bug#14744: 24.3.50; Flickering mouse-face on process output

[Eli Zaretskii]

> From: Christopher Schmidt <christopher@ch.ristopher.com>
> Date: Sat,  3 Aug 2013 10:41:23 +0100 (BST)
> 
> > I guess one way of fixing this problem would be to modify comint.el
> > not to use overlays for this purpose.
> 
> This works around the underlying issue.  There are other real use cases
> in which, due to whatever reason, a redisplay is enforced and this
> artifact appears.

In the absence of a solution for all of them, fixing some of them
would be good nevertheless.  comint is a widely used infrastructure,
so modifying it is likely to solve quite a few of those cases.

Btw, not every case that forces a redisplay cycle actually redraws the
screen.  Emacs display engine has the last line of defense, in that,
after the display engine determines what should be on the screen, it
compares that with what actually is on the screen, and only redraws
the parts that are different.  However, places which have
mouse-highlight are always redrawn (because mouse pointer can move
asynchronously and independently of what Emacs does).

bug#14744: 24.3.50; Flickering mouse-face on process output

[Christopher Schmidt]

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

Eli Zaretskii <eliz@gnu.org> writes:
> In the absence of a solution for all of them, fixing some of them
> would be good nevertheless.  comint is a widely used infrastructure,
> so modifying it is likely to solve quite a few of those cases.

How about this:

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-diff, Size: 3401 bytes --]

--- lisp/comint.el
+++ lisp/comint.el
@@ -636,7 +636,7 @@
   (setq-local comint-last-input-start (point-min-marker))
   (setq-local comint-last-input-end (point-min-marker))
   (setq-local comint-last-output-start (make-marker))
-  (make-local-variable 'comint-last-prompt-overlay)
+  (make-local-variable 'comint-last-prompt)
   (make-local-variable 'comint-prompt-regexp)        ; Don't set; default
   (make-local-variable 'comint-input-ring-size)      ; ...to global val.
   (make-local-variable 'comint-input-ring)
@@ -1902,21 +1902,24 @@
   "If nil, Comint will interpret `carriage control' characters in output.
 See `comint-carriage-motion' for details.")
 
-;; When non-nil, this is an overlay over the last recognized prompt in
-;; the buffer; it is used when highlighting the prompt.
-(defvar comint-last-prompt-overlay nil)
+(defvar comint-last-prompt nil
+  "Markers pointing to the last prompt.
+If non-nil, a cons cell containing markers.  The car points to
+the start, the cdr to the end of the last prompt recognized.")
 
 (defun comint-snapshot-last-prompt ()
-  "`snapshot' any current `comint-last-prompt-overlay'.
-Freeze its attributes in place, even when more input comes along
-and moves the prompt overlay."
-  (when comint-last-prompt-overlay
-    (let ((inhibit-read-only t))
-      (with-silent-modifications
-        (add-text-properties
-         (overlay-start comint-last-prompt-overlay)
-         (overlay-end comint-last-prompt-overlay)
-         (overlay-properties comint-last-prompt-overlay))))))
+  "Snapshot the current `comint-last-prompt'.
+Freezes the `font-lock-face' text property in place."
+  (when comint-last-prompt
+    (with-silent-modifications
+      (add-text-properties
+       (car comint-last-prompt)
+       (cdr comint-last-prompt)
+       '(font-lock-face comint-highlight-prompt)))
+    ;; Reset comint-last-prompt so later on comint-output-filter does
+    ;; not remove the font-lock-face text property of the previous
+    ;; (this) prompt.
+    (setq comint-last-prompt nil)))
 
 (defun comint-carriage-motion (start end)
   "Interpret carriage control characters in the region from START to END.
@@ -2063,20 +2066,15 @@
                   (add-text-properties
                    prompt-start (point)
                    '(read-only t rear-nonsticky t front-sticky (read-only)))))
-	      (unless (and (bolp) (null comint-last-prompt-overlay))
-		;; Need to create or move the prompt overlay (in the case
-		;; where there is no prompt ((bolp) == t), we still do
-		;; this if there's already an existing overlay).
-		(if comint-last-prompt-overlay
-		    ;; Just move an existing overlay
-		    (move-overlay comint-last-prompt-overlay
-				  prompt-start (point))
-		  ;; Need to create the overlay
-		  (setq comint-last-prompt-overlay
-			(make-overlay prompt-start (point)))
-		  (overlay-put comint-last-prompt-overlay
-			       'font-lock-face 'comint-highlight-prompt))))
-
+	      (when comint-last-prompt
+		(remove-text-properties (car comint-last-prompt)
+					(cdr comint-last-prompt)
+					'(font-lock-face)))
+	      (setq comint-last-prompt
+		    (cons (copy-marker prompt-start) (point-marker)))
+	      (add-text-properties (car comint-last-prompt)
+				   (cdr comint-last-prompt)
+				   '(font-lock-face comint-highlight-prompt)))
 	    (goto-char saved-point)))))))
 
 (defun comint-preinput-scroll-to-bottom ()

[-- Attachment #3: Type: text/plain, Size: 21 bytes --]


        Christopher

bug#14744: 24.3.50; Flickering mouse-face on process output

[Eli Zaretskii]

> From: Christopher Schmidt <christopher@ch.ristopher.com>
> Date: Sat,  3 Aug 2013 13:25:39 +0100 (BST)
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > In the absence of a solution for all of them, fixing some of them
> > would be good nevertheless.  comint is a widely used infrastructure,
> > so modifying it is likely to solve quite a few of those cases.
> 
> How about this:

Looks fine to me, although I just skimmed through it.  Does it solve
the problem?

bug#14744: 24.3.50; Flickering mouse-face on process output

[Christopher Schmidt]

Eli Zaretskii <eliz@gnu.org> writes:
> Looks fine to me, although I just skimmed through it.  Does it solve
> the problem?

Yes, it does.

        Christopher

bug#14744: 24.3.50; Flickering mouse-face on process output

[Eli Zaretskii]

> From: Christopher Schmidt <christopher@ch.ristopher.com>
> Date: Sat,  3 Aug 2013 13:56:48 +0100 (BST)
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > Looks fine to me, although I just skimmed through it.  Does it solve
> > the problem?
> 
> Yes, it does.

Then I recommend to install it, barring any objections.

bug#14744: 24.3.50; Flickering mouse-face on process output

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Eli Zaretskii <eliz@gnu.org> writes:
>> > Looks fine to me, although I just skimmed through it.  Does it solve
>> > the problem?
>> 
>> Yes, it does.
>
> Then I recommend to install it, barring any objections.

Looks like this was applied, but the bug report wasn't closed, so I'm
doing that now.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#14744: 24.3.50; Flickering mouse-face on process output

[Stefan Monnier]

>> emacs -q
>> C-x 2
>> M-x shell RET
>> cat /dev/urandom RET
>> C-x o
>> # Move mouse on one of the buttons so the face changes to highlight
>> The button flickers here.
>> Xorg and GTK+ 2.24.10 on GNU/Linux and current Emacs trunk.  This issue
>> is easily reproducible on older Emacsen, such as 24.3 or 23.4.

> Redisplay of a window always includes redisplay of the tool bar.  The
> latter involves drawing the buttons, and then applying the depressed
> faced to the button that the mouse pointer hovers above.  That is what
> you see, I believe.  So why do you consider that a bug?

I consider it a bug because some part of the screen flickers.
I understand the underlying technical reason why Emacs does that, but
it's still a misfeature.  Ideally we should refrain from redrawing
things that haven't changed, and the second best fix is to use some kind
of double buffering so the intermediate "drawn but not depressed" state
is kept hidden.


        Stefan

bug#14744: 24.3.50; Flickering mouse-face on process output

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Christopher Schmidt <christopher@ch.ristopher.com>,  14744@debbugs.gnu.org
> Date: Sat, 29 Jun 2013 11:08:51 -0400
> 
> I consider it a bug because some part of the screen flickers.
> I understand the underlying technical reason why Emacs does that, but
> it's still a misfeature.

See my other message, where I explained the reasons for this specific
case.  Not surprisingly, it's use of overlays.

> Ideally we should refrain from redrawing things that haven't
> changed

We do, but not with mouse-highlight.

> the second best fix is to use some kind of double buffering so the
> intermediate "drawn but not depressed" state is kept hidden.

I admit that I have no idea what you have in mind here, but patches
are most welcome.