2020-04-08 09:39:41 +00:00
|
|
|
% notcurses_refresh(3)
|
|
|
|
% nick black <nickblack@linux.com>
|
2020-08-27 16:43:28 +00:00
|
|
|
% v1.6.19
|
2020-04-08 09:39:41 +00:00
|
|
|
|
|
|
|
# NAME
|
|
|
|
|
|
|
|
notcurses_refresh - redraw an externally-damaged display
|
|
|
|
|
|
|
|
# SYNOPSIS
|
|
|
|
|
2020-04-19 22:46:32 +00:00
|
|
|
**#include <notcurses/notcurses.h>**
|
2020-04-08 09:39:41 +00:00
|
|
|
|
|
|
|
**int notcurses_refresh(const struct notcurses* nc, int* restrict rows, int* restrict cols);**
|
|
|
|
|
|
|
|
# DESCRIPTION
|
|
|
|
|
|
|
|
**notcurses_refresh** clears the screen, homes the cursor, checks the current
|
|
|
|
terminal geometry, and repaints the most recently rendered frame. It can be
|
|
|
|
called concurrently with all other Notcurses functions save
|
|
|
|
**notcurses_render**. **notcurses_refresh** ought be called when the screen is
|
|
|
|
externally damaged (as occurs when another program writes to the terminal, or
|
|
|
|
if your program writes to the terminal using standard I/O). It is necessary to
|
|
|
|
use **notcurses_refresh** in such a case (as opposed to simply calling
|
|
|
|
**notcurses_render**), since **notcurses_render** optimizes its output by only
|
|
|
|
writing internally-damaged cells. Notcurses has no way of knowing about
|
|
|
|
external corruption; by tradition, Ctrl+L is bound to **notcurses_refresh**,
|
|
|
|
and the user is responsible for requesting a hard redraw.
|
|
|
|
|
|
|
|
A secondary use of this function is when the program is blocking on input (and
|
|
|
|
perhaps not ready to render), and receives an **NCKEY_RESIZE** event (see
|
|
|
|
**notcurses_input**). In this case, **notcurses_refresh** will acquire the new
|
|
|
|
screen parameters, and repaint what it can. If you're prepared to call
|
|
|
|
**notcurses_render**, it's better to do that in this case, and thus avoid
|
|
|
|
unnecessary screen redrawing.
|
|
|
|
|
|
|
|
If **rows** and/or **cols** is not NULL, they receive the new geometry.
|
|
|
|
|
|
|
|
# NOTES
|
|
|
|
|
|
|
|
If your program **is** in a render loop (i.e. rendering as quickly as
|
|
|
|
possible, or at least at the refresh rate), there's not much point in
|
|
|
|
erecting the machinery to trigger **notcurses_refresh** based off
|
|
|
|
**NCKEY_RESIZE**. The latter is generated based upon receipt of the **SIGWINCH**
|
|
|
|
signal, which is fundamentally racy with regards to the rest of the program.
|
|
|
|
If your program truly relies on timely invocation of **notcurses_refresh**,
|
|
|
|
it's a broken program. If you don't rely on it in a causal fashion, then just
|
|
|
|
wait for the upcoming render.
|
|
|
|
|
|
|
|
Highest performance in a rendering loop would actually call for disabling
|
|
|
|
Notcurses's **SIGWINCH** handling in the call to **notcurses_init**, so that no
|
|
|
|
time is spent handling a signal you're not going to use.
|
|
|
|
|
|
|
|
# RETURN VALUES
|
|
|
|
|
|
|
|
Returns 0 on success, and -1 on failure. The causes for failure include system
|
|
|
|
error, programming error, closing of output, or allocation failure. None
|
|
|
|
of these are particularly good things, and the most reasonable response to a
|
|
|
|
**notcurses_refresh** failure is either to ignore it, or to weep and exit.
|
|
|
|
|
|
|
|
# SEE ALSO
|
|
|
|
|
|
|
|
**notcurses_init(3)**,
|
|
|
|
**notcurses_input(3)**,
|
|
|
|
**notcurses_render(3)**,
|
|
|
|
**termios(3)**,
|
|
|
|
**signal(7)**
|