[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: redisplay and expose_frame

From: Eli Zaretskii
Subject: Re: redisplay and expose_frame
Date: Sun, 22 Jul 2018 17:37:33 +0300

> Date: Sun, 22 Jul 2018 13:44:18 +0100
> From: Alan Third <address@hidden>
> 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

> 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

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]