GNU bug report logs - #32932
27.0.50; render bugs on macOS Mojave

Previous Next

Full log

Message #137 received at 32932 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: alan <at> idiocy.org, 32932 <at> debbugs.gnu.org, boris <at> d12frosted.io
Subject: Re: bug#32932: 27.0.50; render bugs on macOS Mojave
Date: Sat, 03 Nov 2018 11:23:08 +0200

> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Thu, 1 Nov 2018 13:29:40 -0700
> Cc: alan <at> idiocy.org, 32932 <at> debbugs.gnu.org, boris <at> d12frosted.io
> 
> On November 1, 2018 at 1:13:05 PM, Eli Zaretskii
> (eliz <at> gnu.org(mailto:eliz <at> gnu.org)) wrote:
> 
> > Thanks, but this is not enough info, I need also to see the actual
> > contents of the current and the desired rows. If they are different,
> > then clearing is justified. You can display a glyph row in GDB using
> > the command pgrowx defined in src/.gdbinit.
> 
> Unfortunately, I’m on a Mac, so AFAIK I can only use lldb.

Doesn't the latest GDB compile on macOS?  I thought it did, but
perhaps that's only available in the GDB Git repo.

> I’ll see what I can figure out.

You can, of course, manually type the equivalents of the commands that
GDB uses in pgrowx.

In an Emacs configured with --enable-checking=yes,glyphs, you can also
use the dump-glyph-row command to the same effect.

> > And which row is the problematic one: the one at Y = 0 or at Y = 637?
> 
> I don’t understand Y=0, is that 0 from where the point is? It’s
> probably the 16th row or so from the top.

The Y coordinate is measured from the top of the window.

> > The large numbers for the desired row in the 3rd sample look bogus to
> > me, unless you have a very tall image there.
> 
> It’s a relatively tall image, yeah.

So the problem is with redrawing the cursor in a screen line that
shows a tall image?  Is there any text before and/or after the image
in the same screen line?

> > > So, the ascent and physics_ascent on the current row are coming back
> > > as 0. Also, the height is different.
> >
> > Sounds improbable to me. Are you sure you caught the right rows?
> 
> Those are the only things emitted when I pressed enter on the image
> file to open it (in this case, from the home buffer with a recent file
> list).

If you want to reproduce the flickering, you need to do whatever
causes redisplay after opening the file.  For example, does it flicker
when you move cursor?  Does cursor blinking cause flickering?  Each
one of these should show you the output that tells which parts of the
glyph row is Emacs actually redrawing.

Previous Next

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