bug#38731: [PATCH] Calculate first glyph to be redrawn when exposing (bug#38731)

[Alan Third <alan@idiocy.org>]

On Fri, Dec 27, 2019 at 07:17:03PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 27 Dec 2019 16:26:20 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: netjune@outlook.com, 38731@debbugs.gnu.org
> > 
> > * src/xdisp.c (expose_area): When the face extends to the end of the
> > line calculate the first glyph to be redrawn rather than assuming it
> > starts at the first glyph in the row.
> 
> Thanks, but can you please explain the rationale behind these changes?
> I'm mildly worried why this is done in generic code, whereas the
> problem was Darwin-specific.

The problem only appears to be Darwin specific as the NS port uses the
expose functionality for all its drawing.

I have a scratch NS branch that draws to an offscreen bitmap using the
normal redisplay routines and it looks fine despite using the same
logic in the NS specific code.

This issue doesn’t show up anywhere else because it’s a rare situation
and will only appear when expose is used to redraw the frame, which
makes it even rarer. If we could force Emacs to redraw using expose on
X or Windows I’m certain the same problem would be observed.

The actual problem is that if there is a face that’s to extend to the
end of the line (for example with global-hl-line-mode) then
expose_area asks draw_glyphs to draw glyph 0 at x coordinate 0, even
though in this case there is horizontal scrolling in effect that means
glyph 0 should be at a negative x coordinate.

In my case I could see that row->x in expose_area was set to -42 but
expose_area called draw_glyphs with an x parameter of 0. This offset
the glyphs on the screen by 42 pixels. I could see this both in
debugging printfs and by actually measuring the difference between the
cursor and the equivalent text as drawn on the screen.

-- 
Alan Third