Re: redisplay and expose_frame

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 22 Jul 2018 13:44:18 +0100
> From: Alan Third <alan@idiocy.org>
> 
> At the moment NS Emacs calls expose_frame from within drawRect which
> works well, however it also does some drawing outside of drawRect

Where is the code that draws outside of drawRect?  Can you point me to
it?

> and I strongly suspect that redisplay_internal must, somehow, call
> expose_frame (or an equivalent)

redisplay_internal does NOT call expose_frame.  See the large
commentary at the beginning of xdisp.c, which explains that
expose_frame is a separate entry point into redisplay.

> Does Emacs explicitly draw to the screen as part of redisplay?

Yes, for some value of "draw".

> If so, where is it doing it?

When redisplay_internal is almost done, you will see it call
update_frame or update_window.  These two functions are implemented in
dispnew.c, and what they do is this:

  . compare the "current" glyph matrix with the "desired" one, and
    determine which part(s) of each window need to be redrawn
  . for each screen line that needs to be redrawn, call the
    terminal-specific hook function to actually redraw (see
    update_text_area)

However, what exactly do the hooks such as write_glyphs and
clear_end_of_line do is up to the terminal code (in your case,
nsterm.m); it could do something very different from actually drawing
characters.

By contrast, expose_frame uses the "current" glyph matrices, assuming
(after it verifies) that the glyph matrix accurately describes what
should be on the glass, and then calls those terminal-specific hook
functions directly, see draw_glyphs.  It bypasses redisplay_internal,
whose job is to generate the "desired" glyph matrix, because
expose_frame doesn't need that step.

Let me know if you need more help with untangling this web.