In some cases, we end up calling render_refresh() multiple times in
the same FDM iteration. This means will render the first update
immediately, and then set the 'pending' flag, causing the updated
content to be rendered in the next frame.
This can cause flicker, or flashes, since we're presenting one or more
intermediate frames until the final content is shown.
Not to mention that it is inefficient to render multiple frames like
this.
Fix by:
* render_refresh() only sets a flag in the terminal
* install an FDM hook; this hook loops all terminals and executes what
render_refresh() _used_ to do (that is, render immediately if we're
not waiting for a frame callback, otherwise set 'pending' flag). for
all terminals that have the 'refresh_needed' flag set.
This adds a flag, -p,--presentation-timings, that enables input lag
measuring using the presentation time Wayland protocol.
When enabled, we store a timestamp when we *send* a key to the
slave. Then, when we commit a frame for rendering to the compositor,
we request presentation feedback. We also store a timestamp for when
the frame was committed.
The 'presented' callback then looks at the input and commit
timestamps, and compares it with the presented timestamp.
The delay is logged at INFO when the delay was less than one frame
interval, at WARN when it was one frame interval, and at ERR when it
was two or more frame intervals.
We also update statistic counters that we log when foot is shut down.
This is used when spawning the slave, to set its current working
directory just before we exec() the client.
In a regular foot instance, we set the cwd from getcwd().
In a foot server instance, each connecting client sends its cwd to the
server, and we use that.
Since fonts are destroyed and removed from the font cache when the
last instance is destroyed, closing the "last" terminal window in
server mode would destroy the fonts, and their glyph caches.
By instantiating the set in main, we ensure the fonts, and the glyph
caches, remain. This makes launching new terminals (much) faster.
Note that in "normal" (non-server) mode, this isn't really necessary,
but also doesn't have any penalty.
Since fonts are cached, this adds no additional memory. However, it
makes the first terminal window in --server mode start much faster,
since the (primary) fonts have already been loaded.
Fallback fonts are still loaded on-demand.
In this mode, foot listens on a UNIX socket and creates terminal
windows when clients connect.
A connecting client sends argc/argv to the server, and the server
instantiates a new terminal window.
When the terminal window is closed, the exit code is sent back to the
client.
