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 22:15:17 +0300

> Date: Mon, 22 Jul 2024 20:02:25 +0100
> From: Alan Third <alan <at> idiocy.org>
> Cc: dmitry <at> gutov.dev, 71866 <at> debbugs.gnu.org
> 
> On Mon, Jul 22, 2024 at 07:10:18PM +0300, Eli Zaretskii wrote:
> > 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?
> 
> I'm not sure if it's possible. The whole thing runs asynchronously.
> The best bet would be to put this:
> 
>   [[FRAME_NS_VIEW (f) layer] display];
> 
> at the end of ns_draw_window_cursor and look at it after that, but the
> display function passes a bitmap off to a system that supposedly tells
> the graphics card to pull in the bitmap using DMA and display it, all
> in a separate thread. So whether it will work or not I don't know.
> 
> It may be possible to access the bitmap and dump it to a file...
> 
>   CGContextRef context = [(EmacsLayer *)[FRAME_NS_VIEW (f) layer] getContext];
>   CGContextFlush (context);
>   void *pixels = CGBitmapContextGetData (context);
>   NSLog(@"pixels: %p, bytes: %lu, %lux%lu", pixels,
>         CGBitmapContextGetHeight (context) *
>         CGBitmapContextGetBytesPerRow (context),
>         CGBitmapContextGetHeight (context),
>         CGBitmapContextGetWidth (context));
> 
> Just before the final ns_unfocus in ns_draw_window_cursor should
> provide data about the image, and in lldb something like
> 
>   mem read -o ~/image.raw --count 10000 pixels --force
> 
> should dump the raw pixels to disk and in theory imagemagick or
> something could read them, but I'm failing to make this work. I think
> count is not bytes, and either way I can't convince imagemagick to
> read the output.

Hmm... doesn't sound very practical to me.

Are there any other ways of understanding why the cursor is sometimes
not shown (and at times even the character under the cursor is not
shown as well)?  If the relation between what the code does and what's
on display is basically impenetrable, how do people debug Emacs
display issues on macOS?

Previous Next

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