wl_display_dispatch() calls poll(), which is unnecessary since we
already know the FD is readable.
Use the more lower level wl_display_read_events() +
wl_display_dispatch_pending().
These require wl_display_prepare_read() to have been called.
The idea is to call wl_display_prepare_read() **before** calling
poll().
Thus, we do this more or less last in wayl_init(), and at the **end**
of the FDM handler.
However, having taking this lock also means we no longer can call
wl_display_roundtrip() directly (it will hang).
So, add a wrapper, wayl_roundtrip(), that cancels the read intent,
does the roundtrip, and then re-acquires the read intent.
This hopefully fixes and issue where the visual focus in/out caused a
render refresh with the *old* size.
This caused the occasional flicker at startup, or when resizing the
window.
By placing the resize call before the visual focus in/out, we ensure
the refresh uses the new size.
This is a temporary workaround. The correct solution is to ensure we
only call refresh() once.
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..
