Since it doesn't block, we need to detect EAGAIN failures and ensure
we actually flush everything.
If we don't, we sooner or later end up in a wayland client library
call that aborts due to the socket buffer being full.
Ideally, we'd simply enable POLLOUT in the FDM. However, we cannot
write *anything* to the wayland socket until we've actually managed to
send everything. This means enabling POLLOUT in the FDM wont work
since we may (*will*) end up trying to write more data to it before
we've flushed it.
So, add a wrapper function, wayl_flush(), that acts as a blocking
variant of wl_display_flush(), by detecting EAGAIN failiures and
calling poll() itself, on the wayland socket only, until all data has
been sent.
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.
When we extract text, we may insert '\n' at the end of each line (or
last column of selection, for block selections).
These newlines doesn't occupy any physical cells, and thus we
must **make** room for them in the extraction buffer.
When extracting text from the selection, we lost the first column on
all rows but the first.
This is because the algorithm changed slightly when we moved to
foreach_selection(); the end-of-line detection is now done on the
first column of the new line, instead of the last column on the
previous line.
Instead of having the renderer calculate, for each cell, whether that
cell is currently selected or not, make selection_update() mark/unmark
the selected cells.
The renderer now only has to look at the cells' 'selected'
attribute. This makes the renderer both smaller and faster.
When background alpha is 1.0 (0xffff), i.e. completely opaque, tell
the compositor this, via wl_surface_set_opaque_region().
This allows it to optimize drawing of surfaces _behind_ our window.
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.
