+ <STRONG>o</STRONG> <EM>curses</EM> knows that the terminal has been written to since the
+ preceding <STRONG>scr_dump</STRONG> call.
+
+ Either of the foregoing conditions means that <EM>curses</EM> cannot assume that
+ the terminal's contents match their representation in <EM>filename</EM>. The
+ former is due to terminal features (such as <STRONG>xterm(1)</STRONG>'s "alternate
+ screen") that couple cursor-positioning mode with a local cache of
+ screen contents. <EM>curses</EM> cannot know whether terminal is displaying
+ from that local cache at the time the application calls <STRONG>scr_init</STRONG>, so it
+ makes a pessimistic assumption that a full redraw is required; see
+ subsection "Cursor Motions" of <STRONG><A HREF="terminfo.5.html">terminfo(5)</A></STRONG>.
+
+ <STRONG>scr_init</STRONG> could be used after <STRONG><A HREF="curs_initscr.3x.html">initscr(3x)</A></STRONG> or <STRONG>system(3)</STRONG> to share the
+ screen with another process that has done a <STRONG>scr_dump</STRONG> after <STRONG><A HREF="curs_initscr.3x.html">endwin(3x)</A></STRONG>.
+ An application that supports suspending its state on exit and
+ subsequent resumption upon later execution might use <STRONG>scr_dump</STRONG> and
+ <STRONG>scr_init</STRONG> thus.