Re: Process: Determining the origin of a command loop.

Re: Process: Determining the origin of a command loop.

[Keith David Bershatsky]

Thank you, Eli, for taking the time to review this particular thread.

Whereas an individual cursor (the real cursor) has very little overhead, an average of approximately 200 fake cursors are indeed semi-costly and merit optimization.  The current draft of crosshairs/visible-fill-column/multiple-fake-cursors relies upon display_and_set_cursor to determine when to generate the goodies.  I would like to optimize/suppress the goodies so that they are erased/redrawn only when absolutely necessary.  Let us assume that we make the following modifications to the Emacs master branch and evaluate the following Lisp code after launching the newly built Emacs from the terminal so that we can see the STDERR trace-redisplay output.  As to the current buffer in this situation, there is no need to erase and redraw the goodies (200 fake cursors) because the cursor is in the
  same location and the buffer is unmodified in all respects.  The only changes are occurring in the *compilation* buffer, which is not the current buffer.  The hallmarks of this situation are "redis
 play_preserve_echo_area (12)".

In a nutshell, I am looking for a way to programmatically detect this situation and suppress redrawing the cursor(s) in the unmodified windows.

(progn
  (trace-redisplay 1)
  (when global-eldoc-mode
    (global-eldoc-mode -1))
  (when jit-lock-context-timer
    (cancel-timer jit-lock-context-timer))
  (setq jit-lock-context-timer nil)
  (when (timerp undo-auto-current-boundary-timer)
    (cancel-timer undo-auto-current-boundary-timer))
  (fset 'undo-auto--undoable-change
        (lambda () (add-to-list 'undo-auto--undoably-changed-buffers (current-buffer))))
  (fset 'undo-auto-amalgamate 'ignore)
  (when blink-cursor-mode
    (blink-cursor-mode -1)
    (when (memq 'blink-cursor-check post-command-hook)
      (remove-hook 'post-command-hook 'blink-cursor-check)))
  (setq compilation-scroll-output t)
  (compile "while :; do echo \"Hello-World\"; sleep 1; done"))

diff --git a/src/xdisp.c b/src/xdisp.c
index 4201bdc..9ed03d3 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -29775,6 +29775,16 @@ display_and_set_cursor (struct window *w, bool on,
   FRAME_RIF (f)->draw_window_cursor (w, glyph_row, x, y,
                                      new_cursor_type, new_cursor_width,
                                      on, active_cursor);
+
+  if (trace_redisplay_p)
+    {
+      Lisp_Object window;
+      XSETWINDOW (window, w);
+      Lisp_Object window_string = Fprin1_to_string (window, Qnil);
+      char *window_char = SSDATA (window_string);
+      fprintf (stderr, "\ndisplay_and_set_cursor (%s):  on (%d) | active (%d)\n",
+                       window_char, on, active_cursor);
+    }
 }

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

> Date: [12-19-2018 07:24:50] <19 Dec 2018 17:24:50 +0200>
> From: Eli Zaretskii <eliz@gnu.org>
> 
> * * *
> >
> > I am unaware of any reason why the cursor in the active window needs updating in this situation.
> 
> The way the code is written, we might move the cursor as part of
> updating the window, and the code doesn't record the fact whether it
> did or didn't move the cursor, or turned it off.  So it always
> redisplays the cursor on the correct place at the end.
> 
> > Q:  How can I determine the origin of the command loop in this situation so that I can suppress the cursor from being updated in the active window?
> 
> I don't really understand the question ("origin of the command loop"?
> what's that?), and more generally, don't see why you would want to
> suppress the cursor update.

Re: Process: Determining the origin of a command loop.

[Eli Zaretskii]

> Date:  Wed, 19 Dec 2018 20:11:57 -0800
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  emacs-devel@gnu.org
> 
> Whereas an individual cursor (the real cursor) has very little overhead, an average of approximately 200 fake cursors are indeed semi-costly and merit optimization.  The current draft of crosshairs/visible-fill-column/multiple-fake-cursors relies upon display_and_set_cursor to determine when to generate the goodies.  I would like to optimize/suppress the goodies so that they are erased/redrawn only when absolutely necessary.  Let us assume that we make the following modifications to the Emacs master branch and evaluate the following Lisp code after launching the newly built Emacs from the terminal so that we can see the STDERR trace-redisplay output.  As to the current buffer in this situation, there is no need to erase and redraw the goodies (200 fake cursors) because the cursor is in t
 he same location and the buffer is unmodified in all respects.  The only changes are occurring in the *compilation* buffer, which is not the current buffer.  The hallmarks of this situation are "redisplay_preserve_echo_area (12)".

I understand, but I think you will have to come up with your own
mechanism to check when the
crosshairs/visible-fill-column/multiple-fake-cursors need to be
updated, because I don't think that can be established from the
physical cursor's position or the need to redraw it.  Since those fake
cursors can be anywhere in the window, and the conditions for updating
them are independent of the conditions for moving point, the logic for
that must be independently designed and implemented, using the data
you maintain for drawing those fake cursors.  If you already track
that data, then all you need is determine whether any of it changed
since the last time.

Cursor drawing (was: Process: Determining the origin of a command loop)

[Stefan Monnier]

I was wondering whether it would make sense to introduce a clear notion
of layers.  IIUC the current situation is:

- redisplay renders buffers into glyph matrix.
- redraw of a clipping region is done by "rendering" the corresponding
  part of a glyph matrix into pixels.

and I'm not completely sure where the cursor and the mouse-face
highlight fit into this picture, but IIUC they're handled in a somewhat
ad-hoc way.

The layering could look like:

- redisplay renders buffers into glyph matrix.
- cursors and crosshairs are rendered into a separate data-structure
  (let's call it "overlay").
- redraw of a clipping region is done by "rendering" the corresponding
  part of a glyph matrix combined with the corresponding part of the
  overlay layer into pixels.

Here we'd have 2 layers (the glyph matrix and the overlay), tho I guess
the idea could be generalized to more layers if there's a need for it.
The advantage would be mostly that the overlay data structure could be
designed completely differently from glyph-matrices, so you don't have
to shoehorn crosshairs into the glyph matrix.

There's a good chance what I'm suggesting makes no sense or wouldn't
help with the actually hard part of the code, because I'm not familiar
enough with it.  If so, please ignore me,


        Stefan

Re: Cursor drawing

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 20 Dec 2018 10:39:53 -0500
> 
> I was wondering whether it would make sense to introduce a clear notion
> of layers.  IIUC the current situation is:
> 
> - redisplay renders buffers into glyph matrix.
> - redraw of a clipping region is done by "rendering" the corresponding
>   part of a glyph matrix into pixels.

This is not entirely accurate, but I'm not yet sure a more accurate
description will matter (I will publish one if we conclude it will
help).  I think what matters for this discussion is the "rendering
into pixels" part: I suspect that you have some mental model of that
which is not entirely consistent with what the code actually does.

So maybe you should say more about how you imagine this works, and how
under that mental model you envision this part:

> - redraw of a clipping region is done by "rendering" the corresponding
>   part of a glyph matrix combined with the corresponding part of the
>   overlay layer into pixels.

The crucial part here, for me, is how this "combination" would be
different from "shoehorning crosshairs into the glyph matrix".  Can
you elaborate on what you had in mind?

> The advantage would be mostly that the overlay data structure could be
> designed completely differently from glyph-matrices

Like what, for example?

Re: Cursor drawing

[Stefan Monnier]

> into pixels" part: I suspect that you have some mental model of that
> which is not entirely consistent with what the code actually does.

I'd be surprised if my mental model is actually consistent with what
happens, yes ;-)

> So maybe you should say more about how you imagine this works, and how
> under that mental model you envision this part:
>> - redraw of a clipping region is done by "rendering" the corresponding
>>   part of a glyph matrix combined with the corresponding part of the
>>   overlay layer into pixels.

I imagine this as being done possibly as;

1- draw the relevant glyphs from the glyph matrix
2- draw the relevant part of the overlay on top of it (with some form of
   transparency so as not to completely overwrite what was drawn in step 1).

> The crucial part here, for me, is how this "combination" would be
> different from "shoehorning crosshairs into the glyph matrix".  Can
> you elaborate on what you had in mind?

The crosshairs don't need to be represented/mentioned in the glyph matrix.

You can just keep in the overlay layer an entry that says "draw vertical
line at pixel column X" and "draw horizontal line at pixel line Y".

>> The advantage would be mostly that the overlay data structure could be
>> designed completely differently from glyph-matrices
> Like what, for example?

Maybe more like an SVG canvas?


        Stefan

Re: Cursor drawing

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Thu, 20 Dec 2018 14:18:22 -0500
> 
> > So maybe you should say more about how you imagine this works, and how
> > under that mental model you envision this part:
> >> - redraw of a clipping region is done by "rendering" the corresponding
> >>   part of a glyph matrix combined with the corresponding part of the
> >>   overlay layer into pixels.
> 
> I imagine this as being done possibly as;
> 
> 1- draw the relevant glyphs from the glyph matrix
> 2- draw the relevant part of the overlay on top of it (with some form of
>    transparency so as not to completely overwrite what was drawn in step 1).
> 
> > The crucial part here, for me, is how this "combination" would be
> > different from "shoehorning crosshairs into the glyph matrix".  Can
> > you elaborate on what you had in mind?
> 
> The crosshairs don't need to be represented/mentioned in the glyph matrix.
> 
> You can just keep in the overlay layer an entry that says "draw vertical
> line at pixel column X" and "draw horizontal line at pixel line Y".

Then this can be done today, without any changes in the architecture
of the display engine.  Any code can draw whatever it wants on top of
what the "normal" window/frame-update code did.  The transparency
issue aside, you will just overwrite portions of the displayed text
according to the pixels you splat on the glass.

IOW, if we take the "fake cursors" as an example, the code which
implements them should just be moved outside of the functions called
from redisplay_window, and into a separate function which will be
called, say, by the frame_up_to_date_hook.

The disadvantage of this is, of course, that the code that draw the
face cursors will be needed to be implemented 4 times, one each for
every terminal-specific backend we support.

> >> The advantage would be mostly that the overlay data structure could be
> >> designed completely differently from glyph-matrices
> > Like what, for example?
> 
> Maybe more like an SVG canvas?

You got me here: I have no idea how that works.

Re: Cursor drawing

[Stefan Monnier]

> Then this can be done today, without any changes in the architecture
> of the display engine.

That's the intention, yes.

> The disadvantage of this is, of course, that the code that draw the
> face cursors will be needed to be implemented 4 times, one each for
> every terminal-specific backend we support.

Indeed.  Tho, we could try and use some existing "standard" drawing
library so as to share most of the code for the GUIs (we'd likely still
need to hand-code the non-GUI case).

>> >> The advantage would be mostly that the overlay data structure could be
>> >> designed completely differently from glyph-matrices
>> > Like what, for example?
>> Maybe more like an SVG canvas?
> You got me here: I have no idea how that works.

I don't either.  I meant some kind of vector graphics.  This might allow
us to offer new features such as drawing arrows going from one buffer
position to another.


        Stefan

Re: Cursor drawing

[Elias Mårtenson]

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

On Fri, 21 Dec 2018, 04:00 Stefan Monnier <monnier@iro.umontreal.ca wrote:

>
> I don't either.  I meant some kind of vector graphics.  This might allow
> us to offer new features such as drawing arrows going from one buffer
> position to another.


For what it's worth, precisely this is something I have wanted to do for a
very long time. I started looking at the rendering code in Emacs to try to
understand how complicated that would be, but I have up pretty quickly.

I guess what I'm trying to say is that this is a feature that would be very
welcome.

Regards,
Elias

[-- Attachment #2: Type: text/html, Size: 1012 bytes --]

Re: Cursor drawing

[Eli Zaretskii]

> From: Elias Mårtenson <lokedhs@gmail.com>
> Date: Fri, 21 Dec 2018 12:03:58 +0800
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel <emacs-devel@gnu.org>
> 
> On Fri, 21 Dec 2018, 04:00 Stefan Monnier <monnier@iro.umontreal.ca wrote:
> 
>  I don't either.  I meant some kind of vector graphics.  This might allow
>  us to offer new features such as drawing arrows going from one buffer
>  position to another.
> 
> For what it's worth, precisely this is something I have wanted to do for a very long time. I started looking at the
> rendering code in Emacs to try to understand how complicated that would be, but I have up pretty quickly.
> 
> I guess what I'm trying to say is that this is a feature that would be very welcome. 

Please describe "the feature" in some more detail.  I might be able to
save you some tinkering with the sources, if nothing else.

Thanks.

Re: Cursor drawing

[Elias Mårtenson]

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

On Fri, 21 Dec 2018 at 15:09, Eli Zaretskii <eliz@gnu.org> wrote:

>
> Please describe "the feature" in some more detail.  I might be able to
> save you some tinkering with the sources, if nothing else.
>

The feature I needed was a way to draw arbitrary graphics on top of the
buffer content. In my case, I wanted to draw arrows between different
symbols in the text, representing dataflow.

Regards,
Elias

[-- Attachment #2: Type: text/html, Size: 734 bytes --]

Re: Cursor drawing

[Eli Zaretskii]

> From: Elias Mårtenson <lokedhs@gmail.com>
> Date: Sat, 22 Dec 2018 00:36:10 +0800
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel <emacs-devel@gnu.org>
> 
> The feature I needed was a way to draw arbitrary graphics on top of the buffer content. In my case, I wanted to
> draw arrows between different symbols in the text, representing dataflow.

Doesn't drawing an image of the arrow fit the bill?

Re: Cursor drawing

[Clément Pit-Claudel]

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

On 21/12/2018 15.05, Eli Zaretskii wrote:
>> From: Elias Mårtenson <lokedhs@gmail.com>
>> Date: Sat, 22 Dec 2018 00:36:10 +0800
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel <emacs-devel@gnu.org>
>>
>> The feature I needed was a way to draw arbitrary graphics on top of the buffer content. In my case, I wanted to
>> draw arrows between different symbols in the text, representing dataflow.
> 
> Doesn't drawing an image of the arrow fit the bill?

I can't answer for Elias, of course, but for the use cases I have in mind I think it wouldn't work. I think Elias' idea is that you would have arrows drawn over the text, pointing from one symbol in the source code to another one.  The DrRacket IDE does this to highlight bound occurrences, for example; I have attached a screenshot.

Clément.

[-- Attachment #2: Screenshot from 2018-12-21 15-27-09.png --]
[-- Type: image/png, Size: 49270 bytes --]

Re: Cursor drawing

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Fri, 21 Dec 2018 15:27:52 -0500
> 
> > Doesn't drawing an image of the arrow fit the bill?
> 
> I can't answer for Elias, of course, but for the use cases I have in mind I think it wouldn't work. I think Elias' idea is that you would have arrows drawn over the text, pointing from one symbol in the source code to another one.  The DrRacket IDE does this to highlight bound occurrences, for example; I have attached a screenshot.

Thanks.

This kind of drawing cannot be part of the display engine, since you
want to draw over the text, and thus redisplay will overwrite portions
of your arrows.  So you need to add code after redisplay cycle
finishes, e.g. in frame_up_to_date_hook, to redraw your arrows.  I
think I already mentioned that up-thread.  Use GUI primitives there to
draw lines and other figures, as the case may be.

Re: Cursor drawing

[Eli Zaretskii]

> Date: Fri, 21 Dec 2018 22:37:31 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> Use GUI primitives there to draw lines and other figures, as the
> case may be.

And probably also remove those at the beginning of each redisplay
cycle, to avoid leaving artifacts on screen when/if redisplay decides
to scroll.

Re: Cursor drawing

[Stefan Monnier]

> This kind of drawing cannot be part of the display engine, since you
> want to draw over the text, and thus redisplay will overwrite portions
> of your arrows.

That's why I was suggesting a separate layer.

> And probably also remove those at the beginning of each redisplay
> cycle, to avoid leaving artifacts on screen when/if redisplay decides
> to scroll.

Another way to look at it is that scrolling the display's pixels can
only be used when both layers (the glyph-matrix and the overlay) were
moved together.


        Stefan

Re: Cursor drawing

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 22 Dec 2018 11:43:31 -0500
> 
> Another way to look at it is that scrolling the display's pixels can
> only be used when both layers (the glyph-matrix and the overlay) were
> moved together.

Alternatively, you could define the scroll region to include both.

Re: Process: Determining the origin of a command loop.

[Keith David Bershatsky]

Thank you, Eli, for the helpful guidance -- greatly appreciated!

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

> Date: [12-20-2018 06:11:20] <20 Dec 2018 16:11:20 +0200>
> From: Eli Zaretskii <eliz@gnu.org>
> 
> * * *
> 
> I understand, but I think you will have to come up with your own
> mechanism to check when the
> crosshairs/visible-fill-column/multiple-fake-cursors need to be
> updated, because I don't think that can be established from the
> physical cursor's position or the need to redraw it.  Since those fake
> cursors can be anywhere in the window, and the conditions for updating
> them are independent of the conditions for moving point, the logic for
> that must be independently designed and implemented, using the data
> you maintain for drawing those fake cursors.  If you already track
> that data, then all you need is determine whether any of it changed
> since the last time.

Process: Determining the origin of a command loop.

[Keith David Bershatsky]

One of the items on my todo list for developing feature requests #22873 (multiple fake cursors) and #17684 (crosshairs and visible fill column) is the suppression of redrawing the cursor(s) in certain windows due to output from an ongoing process in one of many visible window.

Let us assume that a user has an _inactive_ window that has ongoing activity; e.g., an *Eshell* buffer is compiling an application and output necessitates that its window be updated.  The user is viewing source code in another window, which may or may not be a different frame all together.  The frame with the *Eshell* buffer may even be hidden behind the active frame.  As output arrives to the *Eshell* buffer, redisplay is updating the cursor in that window and also the active window.

I am unaware of any reason why the cursor in the active window needs updating in this situation.

Q:  How can I determine the origin of the command loop in this situation so that I can suppress the cursor from being updated in the active window?

BACKGROUND:  In general (with some exceptions), multiple fake cursors, crosshairs and the visible fill column are redrawn whenever the real cursor gets updated.

Thanks,

Keith

Re: Process: Determining the origin of a command loop.

[Eli Zaretskii]

> Date: Tue, 18 Dec 2018 20:34:48 -0800
> From: Keith David Bershatsky <esq@lawlist.com>
> 
> One of the items on my todo list for developing feature requests #22873 (multiple fake cursors) and #17684 (crosshairs and visible fill column) is the suppression of redrawing the cursor(s) in certain windows due to output from an ongoing process in one of many visible window.
> 
> Let us assume that a user has an _inactive_ window that has ongoing activity; e.g., an *Eshell* buffer is compiling an application and output necessitates that its window be updated.  The user is viewing source code in another window, which may or may not be a different frame all together.  The frame with the *Eshell* buffer may even be hidden behind the active frame.  As output arrives to the *Eshell* buffer, redisplay is updating the cursor in that window and also the active window.
> 
> I am unaware of any reason why the cursor in the active window needs updating in this situation.

The way the code is written, we might move the cursor as part of
updating the window, and the code doesn't record the fact whether it
did or didn't move the cursor, or turned it off.  So it always
redisplays the cursor on the correct place at the end.

> Q:  How can I determine the origin of the command loop in this situation so that I can suppress the cursor from being updated in the active window?

I don't really understand the question ("origin of the command loop"?
what's that?), and more generally, don't see why you would want to
suppress the cursor update.