Any changes done in any of the configure events are ignored before
we've ack:ed the configure event.
In particular, this means the resize done in xdg-toplevel-configure
isn't displayed until the next time we call render_refresh().
Unless we do something ourselves, this can take quite some time, since
we're basically need the slave to write something.
So, in xdg-surface-configure, *after* having ack:ed the configure
event, call render_refresh() to make the changes done in
xdg-toplevel-configure visible as soon as possible.
This fixes an issue where rendering the 'search' box caused the last
normal buffer from being purged.
This meant the terminal had a pointer to a now freed buffer, which we
de-referenced and occasionally memcpy:ied from.
We can now lookup terminal instances at all times, making it
unnecessary to detect "early" configure events.
Note that we still need to prevent a resize from happening when
width/height is 0.
Instead of having `wayl_win_init()` call
`wl_display_roundtrip()` (which it itself doesn't need), call it from
`term_init()`.
This allows us to add ourselves (the new terminal instance) to the
terminal list in the wayland backend, before triggering the wayland
events caused by `wayl_win_init()`.
This is turn allows the wayland backend to find/lookup the new
terminal when those events occur..
This allows us to measure the time between to refresh delays. That is,
when we decide to delay a refresh, we store the current time.
If we hit that code path _again_, without having refreshed, we
calculate the time that has passed.
This gives us an estimate for how we should set our lower delay
timeout.
This is of course application dependent, but is still much better than
simply guessing a value...
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.
