mirrors/foot
1
0
Fork 0
mirror of https://codeberg.org/dnkl/foot.git synced 2026-03-24 09:05:48 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

term: ptmx: don't set 'pending' flag when app sync updates are in use

Browse source
This commit is contained in:
Daniel Eklöf 2020-03-17 16:32:57 +01:00
parent a2774878ef
commit 29c781b832
No known key found for this signature in database
GPG key ID: 5BBD4992C116573F
1 changed files with 34 additions and 38 deletions
Download patch file Download diff file Expand all files Collapse all files

72
terminal.c
View file

@ -172,41 +172,37 @@ fdm_ptmx(struct fdm *fdm, int fd, int events, void *data)
vt_from_slave(term, buf, count); vt_from_slave(term, buf, count);
} }
/* if (!term->render.app_sync_updates.enabled &&
* We likely need to re-render. But, we don't want to do it !term->render.app_sync_updates.flipped)
* immediately. Often, a single client update is done through {
* multiple writes. This could lead to us rendering one frame with /*
* "intermediate" state. * We likely need to re-render. But, we don't want to do it
* * immediately. Often, a single client update is done through
* For example, we might end up rendering a frame * multiple writes. This could lead to us rendering one frame with
* where the client just erased a line, while in the * "intermediate" state.
* next frame, the client wrote to the same line. This *
* causes screen "flickering". * For example, we might end up rendering a frame
* * where the client just erased a line, while in the
* Mitigate by always incuring a small delay before * next frame, the client wrote to the same line. This
* rendering the next frame. This gives the client * causes screen "flickering".
* some time to finish the operation (and thus gives *
* us time to receive the last writes before doing any * Mitigate by always incuring a small delay before
* actual rendering). * rendering the next frame. This gives the client
* * some time to finish the operation (and thus gives
* We incur this delay *every* time we receive * us time to receive the last writes before doing any
* input. To ensure we don't delay rendering * actual rendering).
* indefinitely, we start a second timer that is only *
* reset when we render. * We incur this delay *every* time we receive
* * input. To ensure we don't delay rendering
* Note that when the client is producing data at a * indefinitely, we start a second timer that is only
* very high pace, we're rate limited by the wayland * reset when we render.
* compositor anyway. The delay we introduce here only *
* has any effect when the renderer is idle. * Note that when the client is producing data at a
*/ * very high pace, we're rate limited by the wayland
if (term->window->frame_callback == NULL) { * compositor anyway. The delay we introduce here only
if (term->render.app_sync_updates.enabled || * has any effect when the renderer is idle.
term->render.app_sync_updates.flipped) */
{ if (term->window->frame_callback == NULL) {
;
}
else {
/* First timeout - reset each time we receive input. */ /* First timeout - reset each time we receive input. */
#if PTMX_TIMING #if PTMX_TIMING
@ -238,9 +234,9 @@ fdm_ptmx(struct fdm *fdm, int fd, int events, void *data)
NULL); NULL);
term->delayed_render_timer.is_armed = true; term->delayed_render_timer.is_armed = true;
} }
} } else
} else term->render.pending.grid = true;
term->render.pending.grid = true; }
if (hup) { if (hup) {
if (term->hold_at_exit) { if (term->hold_at_exit) {