GNU bug report logs - #71866
30.0.50; [macOS] Cursor hiding char behind it with certain theme customization

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: dmitry <at> gutov.dev, 71866 <at> debbugs.gnu.org
Subject: bug#71866: 30.0.50; [macOS] Cursor hiding char behind it with certain theme customization
Date: Mon, 22 Jul 2024 19:10:18 +0300

> Date: Mon, 22 Jul 2024 16:27:30 +0100
> From: Alan Third <alan <at> idiocy.org>
> Cc: Dmitry Gutov <dmitry <at> gutov.dev>, 71866 <at> debbugs.gnu.org
> 
> On Mon, Jul 22, 2024 at 05:45:44PM +0300, Eli Zaretskii wrote:
> > 
> > Thanks.  There's a disturbing discrepancy between what the debugger
> > says about the calls to ns_draw_window_cursor and what I see on
> > display.  For example, there are only 2 events where one of the two
> > Emacs frames begins showing a filled-block cursor (from some other
> > cursor display): at step "1" and step "3".  But the backtraces you
> > collected tell a different story: the only calls with
> > FILLED_BOX_CURSOR are at steps "1" and "7".  At step "3", the debugger
> > claims we called ns_draw_window_cursor with NO_CURSOR, whereas the
> > video clearly shows that the cursor is drawn as a filled block!  This
> > issue alone already makes all this quite mysterious and hard to
> > interpret.
> > 
> > Moreover, the only event in the video where a previously-displayed
> > cursor disappears in one of the windows is the last part, where you
> > type "c" and the debugger says "Process 7616 resuming".  And that
> > happens without ns_draw_window_cursor being called!
> > 
> > So I think there's some factor at work here that we are not
> > considering.  Perhaps it's the macOS window-system or something.
> 
> Hi Eli,
> 
> The macOS display system is inherently double buffered, so there's no
> way to draw directly to the screen. This means any action taken won't
> be displayed on the screen until the NS run loop has run at least
> once. That occurs in the ns_select and ns_read_socket functions.

So how would you suggest to arrange the breakpoints to be able to
match calls to ns_draw_window_cursor with what appears on the screen?

Or maybe we can call some function after ns_draw_window_cursor returns
to make sure the results of ns_draw_window_cursor are immediately
shown on the glass?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.