[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
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.