emacs-devel
[Top][All Lists]
Advanced

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

Re: nsterm.m: How to prevent _inactive_ window update from overreaching.


From: Keith David Bershatsky
Subject: Re: nsterm.m: How to prevent _inactive_ window update from overreaching.
Date: Mon, 26 Nov 2018 20:58:59 -0800

Feature requests #17684 (crosshairs / visible fill column) and #22873 (multiple 
fake cursors) have not been approved by anyone on the Emacs development team.  
There has been some discussion regarding whether multiple fake cursors should 
become a part of Emacs someday, but nothing was ever decided.  I continue to 
develop these features because I use them in my every day workflow and am 
hoping to convince the Emacs development team to someday include similar 
features.  I figure that if I do a good enough job, eventually the Emacs 
development team will say:  "sure, why not ..."

-  Fake cursors are removed in two (2) locations within redisplay_internal (if 
the cursor cache exists).  If the frame is not being updated, then call 
update_begin before removing and call update_end when removing is complete.

-  Fake cursors are removed in two (2) locations within redisplay_window (if 
the cursor cache exists).  If the frame is not being updated, then call 
update_begin before removing and call update_end when removing is complete.

-  Whenever display_and_set_cursor is called and not immediately returned, fake 
cursors are calculated and drawn; or if the cursor cache already exist, then 
erase and redraw.  If the frame is not being updated, then call update_begin 
before drawing/removing and call update_end when drawing/removing is complete.

-  The calculations for drawing fake cursors are based upon modified versions 
of the functions dump_glyph_matrix and dump_glyph_row, which generate the 
correct coordinates for placing the fake cursors.

-  Fake cursors come in two types:  (1) cursor with a glyph on top; (2) cursor 
with nothing on top [e.g., floating anywhere on the visible window].

-  There are two basic settings:  (1) draw or erase/redraw forthwith (whenever 
the real cursor would ordinarily be drawn); or, (2) draw on an idle-timer and, 
if the cursor cache exists, then erase/redraw in certain circumstances when the 
real cursor would ordinarily be redrawn.  New calculations and cursor cache 
update occur on the initial call of either of the two scenarios.

The present design calculates and draws/erases fake cursors based upon 
particular visible windows that get updated during redisplay, rather than 
rectangles within a particular window or set of windows.  If I am understanding 
your comments correctly, it sounds like a new rectangle system of fake cursor 
calculation and drawing/erasing of fake cursors would need to be designed 
(solely for the benefit of MacOS Mojave users).  Or, at the very least, 
calculate fake cursors once for each visible window (where fake cursors are 
active) and then loop through cached coordinates when a rectangle is drawn to 
see if any fake cursors are contained within -- if so, then draw/erase fake 
cursors within that rectangle.

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

> Date: [11-26-2018 12:09:02] <26 Nov 2018 20:09:02 +0000>
> From: Alan Third <address@hidden>
> To: Keith David Bershatsky <address@hidden>
> Cc: address@hidden
> Subject: Re: nsterm.m: How to prevent _inactive_ window update from 
> overreaching.
> 
> * * *
> 
> Because we can't draw directly to the screen any more, when redisplay
> is running all we can do is mark the parts of the frame that need
> updated. Later we call expose_frame on those parts and it does the
> actual drawing.
> 
> That process must be working to some extent. I don't know your code
> very well but I suspect the crosshair code is called when the cursor
> is redrawn. If part of the frame is marked as dirty, but that doesn't
> include the cursor, then the cursor isn't redrawn and therefore your
> crosshair code will not be called. Does that make sense?
> 
> If that is the case we need to work out how to ensure the crosshair
> code is called even if the cursor is not redrawn.
> 
> I've had a quick look at the patches and, if I'm honest, it would take
> me some time to work out what's going on. How is the crosshair drawn?
> --
> Alan Third



reply via email to

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