mirrors/foot
1
0
Fork 0
mirror of https://codeberg.org/dnkl/foot.git synced 2026-02-05 04:06:08 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions
foot/render.c

2124 lines
67 KiB
C
Raw Normal View History

render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
#include "render.h"
#include <string.h>
threads: set thread titles
2019-08-01 20:09:16 +02:00
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
#include <sys/ioctl.h>
render: time how long time it takes to render a frame
2019-07-18 09:33:49 +02:00
#include <sys/time.h>
blink: implement 'blink'
2019-07-21 20:11:20 +02:00
#include <sys/timerfd.h>
threads: set thread titles
2019-08-01 20:09:16 +02:00
#include <sys/prctl.h>
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
render: load cursor theme from XCURSOR_THEME and XCURSOR_SIZE
2019-07-05 10:44:09 +02:00
#include <wayland-cursor.h>
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
#include <xdg-shell.h>
wayland: optionally use the presentation time protocol to measure input lag 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.
2019-12-31 15:39:40 +01:00
#include <presentation-time.h>
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
fcft: include <fcft/fcft.h>, and use fcft/stride.h instead of local copy
2019-12-01 14:03:24 +01:00
#include <fcft/fcft.h>
fcft: use fcft instead of local copy of font.c/font.h
2019-12-01 13:43:51 +01:00
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
#define LOG_MODULE "render"
#define LOG_ENABLE_DBG 0
#include "log.h"
render: reflow: no need to mark new rows as dirty
2020-02-15 18:58:36 +01:00
#include "config.h"
wip: grid is now represented as a grid, not a linear array The grid is now represented with an array of row *pointers*. Each row contains an array of cells (the row's columns). The main point of having row pointers is we can now move rows around almost for free. This is useful when scrolling with scroll margins for example, where we previously had to copy the lines in the margins. Now it's just a matter of swapping two pointers.
2019-07-08 13:57:31 +02:00
#include "grid.h"
search: enable/disable weston sub-surface desync quirk when rendering search box
2020-03-01 13:06:00 +01:00
#include "quirks.h"
render: reflow: no need to mark new rows as dirty
2020-02-15 18:58:36 +01:00
#include "selection.h"
#include "shm.h"
util.h: new header file defining commonly used macros
2020-05-01 11:46:24 +02:00
#include "util.h"
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
render: use shm_scroll() when we believe it will be faster shm_scroll() is fast when memmove() is slow. That is, when scrolling a *small* amount of lines, shm_scroll() is fast. Conversely, when scrolling a *large* number of lines, memmove() is fast. For now, assume the two methods perform _roughly_ the same given a certain number of bytes they have to touch. This means we should use shm_scroll() when number of scroll lines is less than half the screen. Otherwise we use memmove. Since we need to repair the bottom scroll region after a shm_scroll, those lines are added to the count when determining which method to use. TODO: * Check if it's worth to do shm scrolling when we have a top scroll region. * Do more performance testing with a) various amount of scrolling lines, and b) larger bottom scroll regions.
2020-03-22 20:22:17 +01:00
#define TIME_FRAME_RENDERING 0
#define TIME_SCROLL_DAMAGE 0
render: trigger terminal refreshes in an FDM hook 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.
2020-01-04 19:49:26 +01:00
struct renderer {
struct fdm *fdm;
struct wayland *wayl;
};
wayland: optionally use the presentation time protocol to measure input lag 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.
2019-12-31 15:39:40 +01:00
static struct {
size_t total;
size_t zero; /* commits presented in less than one frame interval */
size_t one; /* commits presented in one frame interval */
size_t two; /* commits presented in two or more frame intervals */
misc: replace all explicit zero-initializers with empty initializers
2020-04-13 12:03:11 +02:00
} presentation_statistics = {};
wayland: optionally use the presentation time protocol to measure input lag 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.
2019-12-31 15:39:40 +01:00
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
static void fdm_hook_refresh_pending_terminals(struct fdm *fdm, void *data);
render: trigger terminal refreshes in an FDM hook 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.
2020-01-04 19:49:26 +01:00
struct renderer *
render_init(struct fdm *fdm, struct wayland *wayl)
{
struct renderer *renderer = calloc(1, sizeof(*renderer));
*renderer = (struct renderer) {
.fdm = fdm,
.wayl = wayl,
};
fdm: add hook priorities There are now three hook priorities: low, normal, high. High priority hooks are executed *first*. Normal next, and last the low priority hooks. The renderer's terminal refresh hook now runs as a normal priority hook.
2020-01-04 23:26:27 +01:00
if (!fdm_hook_add(fdm, &fdm_hook_refresh_pending_terminals, renderer,
FDM_HOOK_PRIORITY_NORMAL))
{
render: trigger terminal refreshes in an FDM hook 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.
2020-01-04 19:49:26 +01:00
LOG_ERR("failed to register FDM hook");
free(renderer);
return NULL;
}
return renderer;
}
void
render_destroy(struct renderer *renderer)
{
if (renderer == NULL)
return;
fdm: add hook priorities There are now three hook priorities: low, normal, high. High priority hooks are executed *first*. Normal next, and last the low priority hooks. The renderer's terminal refresh hook now runs as a normal priority hook.
2020-01-04 23:26:27 +01:00
fdm_hook_del(renderer->fdm, &fdm_hook_refresh_pending_terminals,
FDM_HOOK_PRIORITY_NORMAL);
renderer: destroy: actually free the renderer instance (doh!)
2020-01-04 23:41:26 +01:00
free(renderer);
render: trigger terminal refreshes in an FDM hook 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.
2020-01-04 19:49:26 +01:00
}
wayland: optionally use the presentation time protocol to measure input lag 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.
2019-12-31 15:39:40 +01:00
static void __attribute__((destructor))
log_presentation_statistics(void)
{
if (presentation_statistics.total == 0)
return;
const size_t total = presentation_statistics.total;
LOG_INFO("presentation statistics: zero=%f%%, one=%f%%, two=%f%%",
100. * presentation_statistics.zero / total,
100. * presentation_statistics.one / total,
100. * presentation_statistics.two / total);
}
static void
sync_output(void *data,
struct wp_presentation_feedback *wp_presentation_feedback,
struct wl_output *output)
{
}
presentation: store input timestamp in a per-commit context This should reduce the risk of mixing up an input timestamp with the corresponding rendered frame.
2020-01-21 18:51:04 +01:00
struct presentation_context {
struct terminal *term;
struct timeval input;
struct timeval commit;
};
wayland: optionally use the presentation time protocol to measure input lag 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.
2019-12-31 15:39:40 +01:00
static void
presented(void *data,
struct wp_presentation_feedback *wp_presentation_feedback,
uint32_t tv_sec_hi, uint32_t tv_sec_lo, uint32_t tv_nsec,
uint32_t refresh, uint32_t seq_hi, uint32_t seq_lo, uint32_t flags)
{
presentation: store input timestamp in a per-commit context This should reduce the risk of mixing up an input timestamp with the corresponding rendered frame.
2020-01-21 18:51:04 +01:00
struct presentation_context *ctx = data;
struct terminal *term = ctx->term;
const struct timeval *input = &ctx->input;
const struct timeval *commit = &ctx->commit;
wayland: optionally use the presentation time protocol to measure input lag 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.
2019-12-31 15:39:40 +01:00
render: presentation: cleanup
2020-01-01 11:37:47 +01:00
const struct timeval presented = {
wayland: optionally use the presentation time protocol to measure input lag 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.
2019-12-31 15:39:40 +01:00
.tv_sec = (uint64_t)tv_sec_hi << 32 | tv_sec_lo,
.tv_usec = tv_nsec / 1000,
};
presentation: store input timestamp in a per-commit context This should reduce the risk of mixing up an input timestamp with the corresponding rendered frame.
2020-01-21 18:51:04 +01:00
bool use_input = (input->tv_sec > 0 || input->tv_usec > 0) &&
timercmp(&presented, input, >);
render: presentation: log both input -> commit and commit -> presented times
2019-12-31 20:01:47 +01:00
char msg[1024];
int chars = 0;
presentation: store input timestamp in a per-commit context This should reduce the risk of mixing up an input timestamp with the corresponding rendered frame.
2020-01-21 18:51:04 +01:00
if (use_input && timercmp(&presented, input, <))
render: presentation: cleanup
2020-01-01 11:37:47 +01:00
return;
presentation: store input timestamp in a per-commit context This should reduce the risk of mixing up an input timestamp with the corresponding rendered frame.
2020-01-21 18:51:04 +01:00
else if (timercmp(&presented, commit, <))
render: presentation: cleanup
2020-01-01 11:37:47 +01:00
return;
LOG_DBG("commit: %lu s %lu µs, presented: %lu s %lu µs",
presentation: store input timestamp in a per-commit context This should reduce the risk of mixing up an input timestamp with the corresponding rendered frame.
2020-01-21 18:51:04 +01:00
commit->tv_sec, commit->tv_usec, presented.tv_sec, presented.tv_usec);
render: presentation: cleanup
2020-01-01 11:37:47 +01:00
render: presentation: log both input -> commit and commit -> presented times
2019-12-31 20:01:47 +01:00
if (use_input) {
struct timeval diff;
presentation: store input timestamp in a per-commit context This should reduce the risk of mixing up an input timestamp with the corresponding rendered frame.
2020-01-21 18:51:04 +01:00
timersub(commit, input, &diff);
render: presentation: log both input -> commit and commit -> presented times
2019-12-31 20:01:47 +01:00
chars += snprintf(&msg[chars], sizeof(msg) - chars,
render: presentation: space between value and "µs"
2019-12-31 20:31:06 +01:00
"input - %lu µs -> ", diff.tv_usec);
render: presentation: log both input -> commit and commit -> presented times
2019-12-31 20:01:47 +01:00
}
struct timeval diff;
presentation: store input timestamp in a per-commit context This should reduce the risk of mixing up an input timestamp with the corresponding rendered frame.
2020-01-21 18:51:04 +01:00
timersub(&presented, commit, &diff);
render: presentation: log both input -> commit and commit -> presented times
2019-12-31 20:01:47 +01:00
chars += snprintf(&msg[chars], sizeof(msg) - chars,
render: presentation: space between value and "µs"
2019-12-31 20:31:06 +01:00
"commit - %lu µs -> ", diff.tv_usec);
wayland: optionally use the presentation time protocol to measure input lag 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.
2019-12-31 15:39:40 +01:00
render: presentation: cleanup
2020-01-01 11:37:47 +01:00
if (use_input) {
presentation: store input timestamp in a per-commit context This should reduce the risk of mixing up an input timestamp with the corresponding rendered frame.
2020-01-21 18:51:04 +01:00
assert(timercmp(&presented, input, >));
timersub(&presented, input, &diff);
render: presentation: cleanup
2020-01-01 11:37:47 +01:00
} else {
presentation: store input timestamp in a per-commit context This should reduce the risk of mixing up an input timestamp with the corresponding rendered frame.
2020-01-21 18:51:04 +01:00
assert(timercmp(&presented, commit, >));
timersub(&presented, commit, &diff);
render: presentation: cleanup
2020-01-01 11:37:47 +01:00
}
wayland: optionally use the presentation time protocol to measure input lag 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.
2019-12-31 15:39:40 +01:00
render: presentation: log both input -> commit and commit -> presented times
2019-12-31 20:01:47 +01:00
chars += snprintf(&msg[chars], sizeof(msg) - chars,
render: presentation: space between value and "µs"
2019-12-31 20:31:06 +01:00
"presented (total: %lu µs)", diff.tv_usec);
wayland: optionally use the presentation time protocol to measure input lag 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.
2019-12-31 15:39:40 +01:00
render: presentation: log both input -> commit and commit -> presented times
2019-12-31 20:01:47 +01:00
unsigned frame_count = 0;
render: presentation: also use seconds when calculating frame interval count
2019-12-31 20:04:44 +01:00
if (tll_length(term->window->on_outputs) > 0) {
render: presentation: log both input -> commit and commit -> presented times
2019-12-31 20:01:47 +01:00
const struct monitor *mon = tll_front(term->window->on_outputs);
render: presentation: clean up frame interval count calculation
2020-01-01 11:19:13 +01:00
frame_count = (diff.tv_sec * 1000000. + diff.tv_usec) / (1000000. / mon->refresh);
render: presentation: log both input -> commit and commit -> presented times
2019-12-31 20:01:47 +01:00
}
wayland: optionally use the presentation time protocol to measure input lag 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.
2019-12-31 15:39:40 +01:00
render: presentation: log both input -> commit and commit -> presented times
2019-12-31 20:01:47 +01:00
presentation_statistics.total++;
if (frame_count >= 2)
presentation_statistics.two++;
else if (frame_count >= 1)
presentation_statistics.one++;
else
presentation_statistics.zero++;
wayland: optionally use the presentation time protocol to measure input lag 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.
2019-12-31 15:39:40 +01:00
render: presentation: log both input -> commit and commit -> presented times
2019-12-31 20:01:47 +01:00
#define _log_fmt "%s (more than %u frames)"
wayland: optionally use the presentation time protocol to measure input lag 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.
2019-12-31 15:39:40 +01:00
render: presentation: log both input -> commit and commit -> presented times
2019-12-31 20:01:47 +01:00
if (frame_count >= 2)
LOG_ERR(_log_fmt, msg, frame_count);
else if (frame_count >= 1)
LOG_WARN(_log_fmt, msg, frame_count);
else
LOG_INFO(_log_fmt, msg, frame_count);
wayland: optionally use the presentation time protocol to measure input lag 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.
2019-12-31 15:39:40 +01:00
render: presentation: log both input -> commit and commit -> presented times
2019-12-31 20:01:47 +01:00
#undef _log_fmt
wayland: optionally use the presentation time protocol to measure input lag 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.
2019-12-31 15:39:40 +01:00
wp_presentation_feedback_destroy(wp_presentation_feedback);
presentation: store input timestamp in a per-commit context This should reduce the risk of mixing up an input timestamp with the corresponding rendered frame.
2020-01-21 18:51:04 +01:00
free(ctx);
wayland: optionally use the presentation time protocol to measure input lag 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.
2019-12-31 15:39:40 +01:00
}
static void
discarded(void *data, struct wp_presentation_feedback *wp_presentation_feedback)
{
presentation: store input timestamp in a per-commit context This should reduce the risk of mixing up an input timestamp with the corresponding rendered frame.
2020-01-21 18:51:04 +01:00
struct presentation_context *ctx = data;
wayland: optionally use the presentation time protocol to measure input lag 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.
2019-12-31 15:39:40 +01:00
wp_presentation_feedback_destroy(wp_presentation_feedback);
presentation: store input timestamp in a per-commit context This should reduce the risk of mixing up an input timestamp with the corresponding rendered frame.
2020-01-21 18:51:04 +01:00
free(ctx);
wayland: optionally use the presentation time protocol to measure input lag 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.
2019-12-31 15:39:40 +01:00
}
static const struct wp_presentation_feedback_listener presentation_feedback_listener = {
.sync_output = &sync_output,
.presented = &presented,
.discarded = &discarded,
};
fcft: adjust to fcft-2.0 API changes * font_*() -> fcft_*() * struct font -> struct fcft_font * struct glyph -> struct fcft_glyph * enum subpixel_order -> enum fcft_subpixel
2020-04-21 19:29:36 +02:00
static struct fcft_font *
render: attrs_to_font: const:ify
2019-12-19 07:28:33 +01:00
attrs_to_font(const struct terminal *term, const struct attributes *attrs)
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
{
int idx = attrs->italic << 1 | attrs->bold;
font: font_from_name() returns an allocated font struct
2019-10-16 21:52:12 +02:00
return term->fonts[idx];
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
}
wip: render background and glyphs using pixman
2019-08-16 20:40:32 +02:00
static inline pixman_color_t
render: replace all usage of cairo with pixman
2019-08-16 22:06:06 +02:00
color_hex_to_pixman_with_alpha(uint32_t color, uint16_t alpha)
wip: render background and glyphs using pixman
2019-08-16 20:40:32 +02:00
{
render: color_hex_to_pixman_with_alpha(): handle alpha == 0 (transparent)
2020-02-28 18:35:21 +01:00
if (alpha == 0)
return (pixman_color_t){0, 0, 0, 0};
render: replace all usage of cairo with pixman
2019-08-16 22:06:06 +02:00
int alpha_div = 0xffff / alpha;
wip: render background and glyphs using pixman
2019-08-16 20:40:32 +02:00
return (pixman_color_t){
render: replace all usage of cairo with pixman
2019-08-16 22:06:06 +02:00
.red = ((color >> 16 & 0xff) | (color >> 8 & 0xff00)) / alpha_div,
.green = ((color >> 8 & 0xff) | (color >> 0 & 0xff00)) / alpha_div,
.blue = ((color >> 0 & 0xff) | (color << 8 & 0xff00)) / alpha_div,
.alpha = alpha,
wip: render background and glyphs using pixman
2019-08-16 20:40:32 +02:00
};
}
render: replace all usage of cairo with pixman
2019-08-16 22:06:06 +02:00
static inline pixman_color_t
color_hex_to_pixman(uint32_t color)
{
/* Count on the compiler optimizing this */
return color_hex_to_pixman_with_alpha(color, 0xffff);
}
wip: render background and glyphs using pixman
2019-08-16 20:40:32 +02:00
static inline void
render: strip 'pixman' from color function names
2020-04-09 13:41:16 +02:00
color_dim(pixman_color_t *color)
wip: render background and glyphs using pixman
2019-08-16 20:40:32 +02:00
{
color->red /= 2;
color->green /= 2;
color->blue /= 2;
}
render: reduce amount of dim while searching scrollback history
2019-08-29 19:33:25 +02:00
static inline void
render: strip 'pixman' from color function names
2020-04-09 13:41:16 +02:00
color_dim_for_search(pixman_color_t *color)
render: reduce amount of dim while searching scrollback history
2019-08-29 19:33:25 +02:00
{
render: don't dim so much when in search mode
2020-04-10 17:51:33 +02:00
color->red /= 2;
color->green /= 2;
color->blue /= 2;
render: reduce amount of dim while searching scrollback history
2019-08-29 19:33:25 +02:00
}
render: add font_baseline() - calculates the y-coordinate for the baseline The old baseline calculation was copy-pasted to a couple of places, and also assumed that the font's height was equal to ascent+descent. While this is typically true, it isn't necessarily so. Now, we assume that height >= ascent+descent, and then position the baseline in "center" (but adjusted for the descent).
2019-08-29 20:39:22 +02:00
static inline int
font_baseline(const struct terminal *term)
{
render: font_baseline(): simply use the primary font's ascent This is what we used as baseline for regular glyphs anyway. Thus, we can update that code to call font_baseline() now. This makes it easier to change how we define the baseline in the future.
2019-11-30 14:51:44 +01:00
return term->fonts[0]->ascent;
render: add font_baseline() - calculates the y-coordinate for the baseline The old baseline calculation was copy-pasted to a couple of places, and also assumed that the font's height was equal to ascent+descent. While this is typically true, it isn't necessarily so. Now, we assume that height >= ascent+descent, and then position the baseline in "center" (but adjusted for the descent).
2019-08-29 20:39:22 +02:00
}
render: render block cursor as a hollow rectangle when unfocused
2019-12-16 21:34:38 +01:00
static void
draw_unfocused_block(const struct terminal *term, pixman_image_t *pix,
const pixman_color_t *color, int x, int y, int cell_cols)
{
pixman_image_fill_rectangles(
PIXMAN_OP_SRC, pix, color, 4,
(pixman_rectangle16_t []){
{x, y, cell_cols * term->cell_width, 1}, /* top */
{x, y, 1, term->cell_height}, /* left */
{x + cell_cols * term->cell_width - 1, y, 1, term->cell_height}, /* right */
{x, y + term->cell_height - 1, cell_cols * term->cell_width, 1}, /* bottom */
});
}
wip: grid is now represented as a grid, not a linear array The grid is now represented with an array of row *pointers*. Each row contains an array of cells (the row's columns). The main point of having row pointers is we can now move rows around almost for free. This is useful when scrolling with scroll margins for example, where we previously had to copy the lines in the margins. Now it's just a matter of swapping two pointers.
2019-07-08 13:57:31 +02:00
static void
render: replace all usage of cairo with pixman
2019-08-16 22:06:06 +02:00
draw_bar(const struct terminal *term, pixman_image_t *pix,
fcft: adjust to fcft-2.0 API changes * font_*() -> fcft_*() * struct font -> struct fcft_font * struct glyph -> struct fcft_glyph * enum subpixel_order -> enum fcft_subpixel
2020-04-21 19:29:36 +02:00
const struct fcft_font *font,
render: replace all usage of cairo with pixman
2019-08-16 22:06:06 +02:00
const pixman_color_t *color, int x, int y)
wip: grid is now represented as a grid, not a linear array The grid is now represented with an array of row *pointers*. Each row contains an array of cells (the row's columns). The main point of having row pointers is we can now move rows around almost for free. This is useful when scrolling with scroll margins for example, where we previously had to copy the lines in the margins. Now it's just a matter of swapping two pointers.
2019-07-08 13:57:31 +02:00
{
font: move metrics from terminal struct to font struct
2019-11-26 18:54:32 +01:00
int baseline = y + font_baseline(term) - term->fonts[0]->ascent;
render: replace all usage of cairo with pixman
2019-08-16 22:06:06 +02:00
pixman_image_fill_rectangles(
PIXMAN_OP_SRC, pix, color,
render: draw_bar: don't assume height == ascent+descent Instead, draw a bar that is ascent+descent tall, positioned around the baseline such that it starts at the ascent and ends at the descent.
2019-08-29 20:41:40 +02:00
1, &(pixman_rectangle16_t){
x, baseline,
font: move metrics from terminal struct to font struct
2019-11-26 18:54:32 +01:00
font->underline.thickness, term->fonts[0]->ascent + term->fonts[0]->descent});
render: implement cursor styles 'bar' and 'underline'
2019-07-22 20:07:34 +02:00
}
wip: grid is now represented as a grid, not a linear array The grid is now represented with an array of row *pointers*. Each row contains an array of cells (the row's columns). The main point of having row pointers is we can now move rows around almost for free. This is useful when scrolling with scroll margins for example, where we previously had to copy the lines in the margins. Now it's just a matter of swapping two pointers.
2019-07-08 13:57:31 +02:00
render: implement cursor styles 'bar' and 'underline'
2019-07-22 20:07:34 +02:00
static void
render: replace all usage of cairo with pixman
2019-08-16 22:06:06 +02:00
draw_underline(const struct terminal *term, pixman_image_t *pix,
fcft: adjust to fcft-2.0 API changes * font_*() -> fcft_*() * struct font -> struct fcft_font * struct glyph -> struct fcft_glyph * enum subpixel_order -> enum fcft_subpixel
2020-04-21 19:29:36 +02:00
const struct fcft_font *font,
render: replace all usage of cairo with pixman
2019-08-16 22:06:06 +02:00
const pixman_color_t *color, int x, int y, int cols)
render: implement cursor styles 'bar' and 'underline'
2019-07-22 20:07:34 +02:00
{
render: replace all usage of cairo with pixman
2019-08-16 22:06:06 +02:00
pixman_image_fill_rectangles(
PIXMAN_OP_SRC, pix, color,
render: fix underline/strikeout positioning There were two errors: * We subtracted half the line width instead of adding it to the baseline * We rounded the line positioning and thickness before the positioning calculation. In particular, rounding the thickness before using it to adjust the position was wrong. Now we round just before the pixman call.
2019-11-30 14:53:22 +01:00
1, &(pixman_rectangle16_t){
fcft: update to 0.3.0 fcft now calculates the underline and strikeout integer positions, making our rendering code much simpler.
2019-12-03 21:00:48 +01:00
x, y + font_baseline(term) - font->underline.position,
cols * term->cell_width, font->underline.thickness});
render: implement cursor styles 'bar' and 'underline'
2019-07-22 20:07:34 +02:00
}
static void
render: replace all usage of cairo with pixman
2019-08-16 22:06:06 +02:00
draw_strikeout(const struct terminal *term, pixman_image_t *pix,
fcft: adjust to fcft-2.0 API changes * font_*() -> fcft_*() * struct font -> struct fcft_font * struct glyph -> struct fcft_glyph * enum subpixel_order -> enum fcft_subpixel
2020-04-21 19:29:36 +02:00
const struct fcft_font *font,
render: replace all usage of cairo with pixman
2019-08-16 22:06:06 +02:00
const pixman_color_t *color, int x, int y, int cols)
render: implement cursor styles 'bar' and 'underline'
2019-07-22 20:07:34 +02:00
{
render: replace all usage of cairo with pixman
2019-08-16 22:06:06 +02:00
pixman_image_fill_rectangles(
PIXMAN_OP_SRC, pix, color,
render: fix underline/strikeout positioning There were two errors: * We subtracted half the line width instead of adding it to the baseline * We rounded the line positioning and thickness before the positioning calculation. In particular, rounding the thickness before using it to adjust the position was wrong. Now we round just before the pixman call.
2019-11-30 14:53:22 +01:00
1, &(pixman_rectangle16_t){
fcft: update to 0.3.0 fcft now calculates the underline and strikeout integer positions, making our rendering code much simpler.
2019-12-03 21:00:48 +01:00
x, y + font_baseline(term) - font->strikeout.position,
cols * term->cell_width, font->strikeout.thickness});
render: implement cursor styles 'bar' and 'underline'
2019-07-22 20:07:34 +02:00
}
render: render_cell: break out cursor rendering
2019-12-19 07:28:49 +01:00
static void
draw_cursor(const struct terminal *term, const struct cell *cell,
fcft: adjust to fcft-2.0 API changes * font_*() -> fcft_*() * struct font -> struct fcft_font * struct glyph -> struct fcft_glyph * enum subpixel_order -> enum fcft_subpixel
2020-04-21 19:29:36 +02:00
const struct fcft_font *font, pixman_image_t *pix, pixman_color_t *fg,
selection: store cell 'selected' state in the cells' attributes 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.
2020-01-04 12:03:04 +01:00
const pixman_color_t *bg, int x, int y, int cols)
render: render_cell: break out cursor rendering
2019-12-19 07:28:49 +01:00
{
pixman_color_t cursor_color;
pixman_color_t text_color;
selection: store cell 'selected' state in the cells' attributes 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.
2020-01-04 12:03:04 +01:00
bool is_selected = cell->attrs.selected;
render: render_cell: break out cursor rendering
2019-12-19 07:28:49 +01:00
if (term->cursor_color.cursor >> 31) {
cursor_color = color_hex_to_pixman(term->cursor_color.cursor);
render: fallback to background color if cursor text color is not set
2020-01-20 18:36:44 +01:00
text_color = color_hex_to_pixman(
term->cursor_color.text >> 31
? term->cursor_color.text : term->colors.bg);
render: render_cell: break out cursor rendering
2019-12-19 07:28:49 +01:00
if (term->reverse ^ cell->attrs.reverse ^ is_selected) {
pixman_color_t swap = cursor_color;
cursor_color = text_color;
text_color = swap;
}
if (term->is_searching && !is_selected) {
render: strip 'pixman' from color function names
2020-04-09 13:41:16 +02:00
color_dim_for_search(&cursor_color);
color_dim_for_search(&text_color);
render: render_cell: break out cursor rendering
2019-12-19 07:28:49 +01:00
}
} else {
cursor_color = *fg;
text_color = *bg;
}
switch (term->cursor_style) {
case CURSOR_BLOCK:
render: use kbd-focus instead of visual focus for hollow block cursor When determining whether we should render a hollow block cursor, i.e. to signal that we're unfocused, base the decision on the terminals current keyboard focus, not visual focus.
2020-07-11 09:06:36 +02:00
if (!term->kbd_focus)
render: render_cell: break out cursor rendering
2019-12-19 07:28:49 +01:00
draw_unfocused_block(term, pix, &cursor_color, x, y, cols);
else if (term->cursor_blink.state == CURSOR_BLINK_ON) {
*fg = text_color;
pixman_image_fill_rectangles(
PIXMAN_OP_SRC, pix, &cursor_color, 1,
&(pixman_rectangle16_t){x, y, cols * term->cell_width, term->cell_height});
}
break;
case CURSOR_BAR:
render: use kbd-focus instead of visual focus for hollow block cursor When determining whether we should render a hollow block cursor, i.e. to signal that we're unfocused, base the decision on the terminals current keyboard focus, not visual focus.
2020-07-11 09:06:36 +02:00
if (term->cursor_blink.state == CURSOR_BLINK_ON || !term->kbd_focus)
render: render_cell: break out cursor rendering
2019-12-19 07:28:49 +01:00
draw_bar(term, pix, font, &cursor_color, x, y);
break;
case CURSOR_UNDERLINE:
render: use kbd-focus instead of visual focus for hollow block cursor When determining whether we should render a hollow block cursor, i.e. to signal that we're unfocused, base the decision on the terminals current keyboard focus, not visual focus.
2020-07-11 09:06:36 +02:00
if (term->cursor_blink.state == CURSOR_BLINK_ON || !term->kbd_focus) {
render: render_cell: break out cursor rendering
2019-12-19 07:28:49 +01:00
draw_underline(
term, pix, attrs_to_font(term, &cell->attrs), &cursor_color,
x, y, cols);
}
break;
}
}
render: special case worker-count == 0 Allow render worker count to be 0, in which case the main thread renders the entire screen.
2019-08-01 20:09:39 +02:00
static int
render: replace all usage of cairo with pixman
2019-08-16 22:06:06 +02:00
render_cell(struct terminal *term, pixman_image_t *pix,
render: render combining characters This is basically just a loop that renders additional glyphs on top off the base glyph. Since we now need access to the row struct, for the combining characters, the function prototype for 'render_cell()' has changed. When rendering the combining characters we also need to deal with broken fonts; some fonts use positive offsets (as if the combining character was a regular character), while others use a negative offset (to be used as if you had already advanced the pen position). We handle both - a positive offset is rendered just like a regular glyph. When we see a negative offset we simply add the width of a cell first.
2020-05-01 11:56:13 +02:00
struct row *row, int col, int row_no, bool has_cursor)
render: implement cursor styles 'bar' and 'underline'
2019-07-22 20:07:34 +02:00
{
render: render combining characters This is basically just a loop that renders additional glyphs on top off the base glyph. Since we now need access to the row struct, for the combining characters, the function prototype for 'render_cell()' has changed. When rendering the combining characters we also need to deal with broken fonts; some fonts use positive offsets (as if the combining character was a regular character), while others use a negative offset (to be used as if you had already advanced the pen position). We handle both - a positive offset is rendered just like a regular glyph. When we see a negative offset we simply add the width of a cell first.
2020-05-01 11:56:13 +02:00
struct cell *cell = &row->cells[col];
render: add a 'clean' bit to each cell; only render cells that aren't clean This patch takes a bit from the foreground color value in a cell (todo: split up foreground/background into bitfields with a separate field for 'foreground/background' has been set), and only re-renders cells that aren't marked as clean. Note: we use a 'clean' bit rather than a 'dirty' bit to make it easy to erase cells - we can (keep doing) do that by simply memsetting a cell range to 0.
2019-07-30 18:03:03 +02:00
if (cell->attrs.clean)
render: special case worker-count == 0 Allow render worker count to be 0, in which case the main thread renders the entire screen.
2019-08-01 20:09:39 +02:00
return 0;
render: add a 'clean' bit to each cell; only render cells that aren't clean This patch takes a bit from the foreground color value in a cell (todo: split up foreground/background into bitfields with a separate field for 'foreground/background' has been set), and only re-renders cells that aren't marked as clean. Note: we use a 'clean' bit rather than a 'dirty' bit to make it easy to erase cells - we can (keep doing) do that by simply memsetting a cell range to 0.
2019-07-30 18:03:03 +02:00
cell->attrs.clean = 1;
render: replace all usage of cairo with pixman
2019-08-16 22:06:06 +02:00
int width = term->cell_width;
int height = term->cell_height;
term: resize: pre-calculate right/bottom margins
2020-02-24 18:38:11 +01:00
int x = term->margins.left + col * width;
render: render combining characters This is basically just a loop that renders additional glyphs on top off the base glyph. Since we now need access to the row struct, for the combining characters, the function prototype for 'render_cell()' has changed. When rendering the combining characters we also need to deal with broken fonts; some fonts use positive offsets (as if the combining character was a regular character), while others use a negative offset (to be used as if you had already advanced the pen position). We handle both - a positive offset is rendered just like a regular glyph. When we see a negative offset we simply add the width of a cell first.
2020-05-01 11:56:13 +02:00
int y = term->margins.top + row_no * height;
render: implement cursor styles 'bar' and 'underline'
2019-07-22 20:07:34 +02:00
selection: update: don't dirty cells that don't change state Previously when updating a selection, we would unmark *all* cells in the old selection, and then mark all cells in the new selection. This caused *all* cells to be dirtied and thus re-rendered. Avoid this, by adding a temporary state to the cells' selected state. Before unmarking the old selection, pre-mark the new selection using a temporary state. When unmarking the old selection, ignore cells in this temporary state. When marking the new selection, ignore cells in this temporary state (except clearing the temporary state).
2020-01-06 11:56:18 +01:00
assert(cell->attrs.selected == 0 || cell->attrs.selected == 1);
selection: store cell 'selected' state in the cells' attributes 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.
2020-01-04 12:03:04 +01:00
bool is_selected = cell->attrs.selected;
render: implement cursor styles 'bar' and 'underline'
2019-07-22 20:07:34 +02:00
render: fix rendering of cursor when cell is reversed When the user had configured the cursor color, we failed to invert (reverse) the foreground and background color when the cursor was on a cell with the 'reverse' attribute set.
2019-11-28 19:22:21 +01:00
uint32_t _fg = 0;
uint32_t _bg = 0;
render: render_cell: break out cursor rendering
2019-12-19 07:28:49 +01:00
/* Use cell specific color, if set, otherwise the default colors (possible reversed) */
_fg = cell->attrs.have_fg ? cell->attrs.fg : term->colors.fg;
_bg = cell->attrs.have_bg ? cell->attrs.bg : term->colors.bg;
wip: grid is now represented as a grid, not a linear array The grid is now represented with an array of row *pointers*. Each row contains an array of cells (the row's columns). The main point of having row pointers is we can now move rows around almost for free. This is useful when scrolling with scroll margins for example, where we previously had to copy the lines in the margins. Now it's just a matter of swapping two pointers.
2019-07-08 13:57:31 +02:00
rgba: drop alpha channel support
2019-07-08 15:56:15 +02:00
/* If *one* is set, we reverse */
render: render_cell: break out cursor rendering
2019-12-19 07:28:49 +01:00
if (term->reverse ^ cell->attrs.reverse ^ is_selected) {
render: shorten foreground/background local variable names
2019-07-16 19:52:45 +02:00
uint32_t swap = _fg;
_fg = _bg;
_bg = swap;
wip: grid is now represented as a grid, not a linear array The grid is now represented with an array of row *pointers*. Each row contains an array of cells (the row's columns). The main point of having row pointers is we can now move rows around almost for free. This is useful when scrolling with scroll margins for example, where we previously had to copy the lines in the margins. Now it's just a matter of swapping two pointers.
2019-07-08 13:57:31 +02:00
}
term: group 'blink' state together in a struct
2019-07-22 19:17:57 +02:00
if (cell->attrs.blink && term->blink.state == BLINK_OFF)
blink: implement 'blink'
2019-07-21 20:11:20 +02:00
_fg = _bg;
wip: render background and glyphs using pixman
2019-08-16 20:40:32 +02:00
pixman_color_t fg = color_hex_to_pixman(_fg);
render: only apply transparency to the default background color
2020-05-16 16:26:52 +02:00
pixman_color_t bg = color_hex_to_pixman_with_alpha(
_bg, _bg == term->colors.bg ? term->colors.alpha : 0xffff);
terminal: foreground/background in cell attributes are now uint32_t This reduces the cell size, and thus improves the cache behavour
2019-07-16 13:17:51 +02:00
render: break out color conversion
2019-07-18 10:04:13 +02:00
if (cell->attrs.dim)
render: strip 'pixman' from color function names
2020-04-09 13:41:16 +02:00
color_dim(&fg);
render: implement 'underline'
2019-07-16 14:20:39 +02:00
render: don't dim selection while searching
2019-08-27 19:40:07 +02:00
if (term->is_searching && !is_selected) {
render: strip 'pixman' from color function names
2020-04-09 13:41:16 +02:00
color_dim_for_search(&fg);
color_dim_for_search(&bg);
search: wip: re-direct input while searching, and build a search buffer This adds a new state, 'is_searching'. While active, input is re-directed, and stored in a search buffer. In the future, we'll use this buffer and search for its content in the scrollback buffer, and move the view and create a selection on matches. When rendering in 'is_searching', everything is dimmed. In the future, we'll render the current search buffer on-top of the dimmed "regular" terminal output.
2019-08-27 17:23:28 +02:00
}
fcft: adjust to fcft-2.0 API changes * font_*() -> fcft_*() * struct font -> struct fcft_font * struct glyph -> struct fcft_glyph * enum subpixel_order -> enum fcft_subpixel
2020-04-21 19:29:36 +02:00
struct fcft_font *font = attrs_to_font(term, &cell->attrs);
render: make 'glyph' assignment more readable
2020-04-26 12:39:42 +02:00
const struct fcft_glyph *glyph = NULL;
unicode-combining: store seen combining chains "globally" in the term struct Instead of storing combining data per cell, realize that most combinations are re-occurring and that there's lots of available space left in the unicode range, and store seen base+combining combinations chains in a per-terminal array. When we encounter a combining character, we first try to pre-compose, like before. If that fails, we then search for the current base+combining combo in the list of previously seen combinations. If not found there either, we allocate a new combo and add it to the list. Regardless, the result is an index into this array. We store this index, offsetted by COMB_CHARS_LO=0x40000000ul in the cell. When rendering, we need to check if the cell character is a plain character, or if it's a composed character (identified by checking if the cell character is >= COMB_CHARS_LO). Then we render the grapheme pretty much like before.
2020-05-03 11:03:22 +02:00
const struct composed *composed = NULL;
render: make 'glyph' assignment more readable
2020-04-26 12:39:42 +02:00
unicode-combining: store seen combining chains "globally" in the term struct Instead of storing combining data per cell, realize that most combinations are re-occurring and that there's lots of available space left in the unicode range, and store seen base+combining combinations chains in a per-terminal array. When we encounter a combining character, we first try to pre-compose, like before. If that fails, we then search for the current base+combining combo in the list of previously seen combinations. If not found there either, we allocate a new combo and add it to the list. Regardless, the result is an index into this array. We store this index, offsetted by COMB_CHARS_LO=0x40000000ul in the cell. When rendering, we need to check if the cell character is a plain character, or if it's a composed character (identified by checking if the cell character is >= COMB_CHARS_LO). Then we render the grapheme pretty much like before.
2020-05-03 11:03:22 +02:00
if (cell->wc != 0) {
wchar_t base = cell->wc;
if (base >= COMB_CHARS_LO &&
base < (COMB_CHARS_LO + term->composed_count))
{
composed = &term->composed[base - COMB_CHARS_LO];
base = composed->base;
}
glyph = fcft_glyph_rasterize(font, base, term->font_subpixel);
}
render: draw cell decorations (cursor, underline etc) correctly for double-width characters
2019-07-31 21:15:40 +02:00
render: regression: don't let cell background overflow into the margins This used to work before because we had a "global" clip region on the text area, excluding the margins. When we introduced per-cell clipping, this global clip region was removed, and the background drawing code could now overflow into the margins. This fixes it by setting the cell clip region not just when rendering a glyph, but before we render the cell background.
2020-06-05 08:10:38 +02:00
const int cols_left = term->cols - col;
int cell_cols = glyph != NULL ? max(1, min(glyph->cols, cols_left)) : 1;
pixman_region32_t clip;
pixman_region32_init_rect(
&clip, x, y,
cell_cols * term->cell_width, term->cell_height);
pixman_image_set_clip_region32(pix, &clip);
render: draw cell decorations (cursor, underline etc) correctly for double-width characters
2019-07-31 21:15:40 +02:00
wip: grid is now represented as a grid, not a linear array The grid is now represented with an array of row *pointers*. Each row contains an array of cells (the row's columns). The main point of having row pointers is we can now move rows around almost for free. This is useful when scrolling with scroll margins for example, where we previously had to copy the lines in the margins. Now it's just a matter of swapping two pointers.
2019-07-08 13:57:31 +02:00
/* Background */
wip: render background and glyphs using pixman
2019-08-16 20:40:32 +02:00
pixman_image_fill_rectangles(
PIXMAN_OP_SRC, pix, &bg, 1,
&(pixman_rectangle16_t){x, y, cell_cols * width, height});
wip: grid is now represented as a grid, not a linear array The grid is now represented with an array of row *pointers*. Each row contains an array of cells (the row's columns). The main point of having row pointers is we can now move rows around almost for free. This is useful when scrolling with scroll margins for example, where we previously had to copy the lines in the margins. Now it's just a matter of swapping two pointers.
2019-07-08 13:57:31 +02:00
render: move blink timer handling to term.c
2019-12-17 19:11:27 +01:00
if (cell->attrs.blink)
term_arm_blink_timer(term);
blink: implement 'blink'
2019-07-21 20:11:20 +02:00
render: use kbd-focus instead of visual focus for hollow block cursor When determining whether we should render a hollow block cursor, i.e. to signal that we're unfocused, base the decision on the terminals current keyboard focus, not visual focus.
2020-07-11 09:06:36 +02:00
if (has_cursor && term->cursor_style == CURSOR_BLOCK && term->kbd_focus)
render: render non-block cursors after rendering the glyph + decorations This fixes an issue where an 'underline' cursor wasn't visible on underlined text - the cursor was rendered first, and then shadowed by the text underline.
2020-03-17 11:47:47 +01:00
draw_cursor(term, cell, font, pix, &fg, &bg, x, y, cell_cols);
cell: pack more efficiently and store glyph as a wchar The 'attributes' struct is now 8 bytes and naturally packed (used to be 9 bytes, artificially packed). 'cell' struct is now 12 bytes, naturally packed (used to be 13 bytes, artificially packed). Furthermore, the glyph is stored as a wchar instead of a char*. This makes it easier (faster) to do glyph lookup when rendering.
2019-08-02 18:19:07 +02:00
if (cell->wc == 0 || cell->attrs.conceal)
render: render non-block cursors after rendering the glyph + decorations This fixes an issue where an 'underline' cursor wasn't visible on underlined text - the cursor was rendered first, and then shadowed by the text underline.
2020-03-17 11:47:47 +01:00
goto draw_cursor;
wip: grid is now represented as a grid, not a linear array The grid is now represented with an array of row *pointers*. Each row contains an array of cells (the row's columns). The main point of having row pointers is we can now move rows around almost for free. This is useful when scrolling with scroll margins for example, where we previously had to copy the lines in the margins. Now it's just a matter of swapping two pointers.
2019-07-08 13:57:31 +02:00
render: don't re-instantiate the foreground pixman source
2020-05-02 22:14:48 +02:00
pixman_image_t *clr_pix = pixman_image_create_solid_fill(&fg);
render: draw cell decorations (cursor, underline etc) correctly for double-width characters
2019-07-31 21:15:40 +02:00
if (glyph != NULL) {
render: re-write cell clipping to use pixman destination clipping Our home rolled clip-to-cell code was, obviously, not correct. The original problem was that we couldn't use pixman clipping since we have multiple threads writing to the same pixman image, and thus there would be races between the threads setting clipping. The fix is actually simple - just instantiate one pixman image (referencing the same backing image data) for each rendering thread.
2020-06-04 15:39:19 +02:00
/* Clip to cell */
render: don't 're-calculate fg unnecessarily
2019-08-18 18:11:38 +02:00
if (unlikely(pixman_image_get_format(glyph->pix) == PIXMAN_a8r8g8b8)) {
render: draw cell decorations (cursor, underline etc) correctly for double-width characters
2019-07-31 21:15:40 +02:00
/* Glyph surface is a pre-rendered image (typically a color emoji...) */
if (!(cell->attrs.blink && term->blink.state == BLINK_OFF)) {
render: use 32-bit pixman calls, where applicable
2019-08-17 17:36:27 +02:00
pixman_image_composite32(
wip: render background and glyphs using pixman
2019-08-16 20:40:32 +02:00
PIXMAN_OP_OVER, glyph->pix, NULL, pix, 0, 0, 0, 0,
render: re-write cell clipping to use pixman destination clipping Our home rolled clip-to-cell code was, obviously, not correct. The original problem was that we couldn't use pixman clipping since we have multiple threads writing to the same pixman image, and thus there would be races between the threads setting clipping. The fix is actually simple - just instantiate one pixman image (referencing the same backing image data) for each rendering thread.
2020-06-04 15:39:19 +02:00
x + glyph->x, y + font_baseline(term) - glyph->y,
glyph->width, glyph->height);
render: draw cell decorations (cursor, underline etc) correctly for double-width characters
2019-07-31 21:15:40 +02:00
}
} else {
render: use 32-bit pixman calls, where applicable
2019-08-17 17:36:27 +02:00
pixman_image_composite32(
render: re-write cell clipping to use pixman destination clipping Our home rolled clip-to-cell code was, obviously, not correct. The original problem was that we couldn't use pixman clipping since we have multiple threads writing to the same pixman image, and thus there would be races between the threads setting clipping. The fix is actually simple - just instantiate one pixman image (referencing the same backing image data) for each rendering thread.
2020-06-04 15:39:19 +02:00
PIXMAN_OP_OVER, clr_pix, glyph->pix, pix, 0, 0, 0, 0,
x + glyph->x, y + font_baseline(term) - glyph->y,
glyph->width, glyph->height);
render: do not allow glyphs to overflow into surrounding cells This would be done cleaner by using destination clipping in pixman, but since we have multiple threads rendering cells simultaneously, that is not possible. We also cannot use source clipping since we need to offset the destination x,y coordinates with the glyph offsets. So, roll our own clipping by not allowing the x,y offsets to go outside the cell boundaries, and adjusting the glyph offset accordingly. Closes #21
2020-06-03 17:32:57 +02:00
/* Combining characters */
if (composed != NULL) {
for (size_t i = 0; i < composed->count; i++) {
const struct fcft_glyph *g = fcft_glyph_rasterize(
font, composed->combining[i], term->font_subpixel);
if (g == NULL)
continue;
pixman_image_composite32(
PIXMAN_OP_OVER, clr_pix, g->pix, pix, 0, 0, 0, 0,
/* Some fonts use a negative offset, while others use a
* "normal" offset */
x + (g->x < 0 ? term->cell_width : 0) + g->x,
y + font_baseline(term) - g->y,
g->width, g->height);
}
}
unicode-combining: store seen combining chains "globally" in the term struct Instead of storing combining data per cell, realize that most combinations are re-occurring and that there's lots of available space left in the unicode range, and store seen base+combining combinations chains in a per-terminal array. When we encounter a combining character, we first try to pre-compose, like before. If that fails, we then search for the current base+combining combo in the list of previously seen combinations. If not found there either, we allocate a new combo and add it to the list. Regardless, the result is an index into this array. We store this index, offsetted by COMB_CHARS_LO=0x40000000ul in the cell. When rendering, we need to check if the cell character is a plain character, or if it's a composed character (identified by checking if the cell character is >= COMB_CHARS_LO). Then we render the grapheme pretty much like before.
2020-05-03 11:03:22 +02:00
}
render: re-write cell clipping to use pixman destination clipping Our home rolled clip-to-cell code was, obviously, not correct. The original problem was that we couldn't use pixman clipping since we have multiple threads writing to the same pixman image, and thus there would be races between the threads setting clipping. The fix is actually simple - just instantiate one pixman image (referencing the same backing image data) for each rendering thread.
2020-06-04 15:39:19 +02:00
render: render combining characters This is basically just a loop that renders additional glyphs on top off the base glyph. Since we now need access to the row struct, for the combining characters, the function prototype for 'render_cell()' has changed. When rendering the combining characters we also need to deal with broken fonts; some fonts use positive offsets (as if the combining character was a regular character), while others use a negative offset (to be used as if you had already advanced the pen position). We handle both - a positive offset is rendered just like a regular glyph. When we see a negative offset we simply add the width of a cell first.
2020-05-01 11:56:13 +02:00
}
unicode-combining: store seen combining chains "globally" in the term struct Instead of storing combining data per cell, realize that most combinations are re-occurring and that there's lots of available space left in the unicode range, and store seen base+combining combinations chains in a per-terminal array. When we encounter a combining character, we first try to pre-compose, like before. If that fails, we then search for the current base+combining combo in the list of previously seen combinations. If not found there either, we allocate a new combo and add it to the list. Regardless, the result is an index into this array. We store this index, offsetted by COMB_CHARS_LO=0x40000000ul in the cell. When rendering, we need to check if the cell character is a plain character, or if it's a composed character (identified by checking if the cell character is >= COMB_CHARS_LO). Then we render the grapheme pretty much like before.
2020-05-03 11:03:22 +02:00
render: don't re-instantiate the foreground pixman source
2020-05-02 22:14:48 +02:00
pixman_image_unref(clr_pix);
render: render combining characters This is basically just a loop that renders additional glyphs on top off the base glyph. Since we now need access to the row struct, for the combining characters, the function prototype for 'render_cell()' has changed. When rendering the combining characters we also need to deal with broken fonts; some fonts use positive offsets (as if the combining character was a regular character), while others use a negative offset (to be used as if you had already advanced the pen position). We handle both - a positive offset is rendered just like a regular glyph. When we see a negative offset we simply add the width of a cell first.
2020-05-01 11:56:13 +02:00
render: implement 'underline'
2019-07-16 14:20:39 +02:00
/* Underline */
render: replace all usage of cairo with pixman
2019-08-16 22:06:06 +02:00
if (cell->attrs.underline) {
draw_underline(term, pix, attrs_to_font(term, &cell->attrs),
render: don't 're-calculate fg unnecessarily
2019-08-18 18:11:38 +02:00
&fg, x, y, cell_cols);
render: replace all usage of cairo with pixman
2019-08-16 22:06:06 +02:00
}
render: implement strikeout
2019-07-16 15:08:02 +02:00
render: replace all usage of cairo with pixman
2019-08-16 22:06:06 +02:00
if (cell->attrs.strikethrough) {
draw_strikeout(term, pix, attrs_to_font(term, &cell->attrs),
render: don't 're-calculate fg unnecessarily
2019-08-18 18:11:38 +02:00
&fg, x, y, cell_cols);
render: replace all usage of cairo with pixman
2019-08-16 22:06:06 +02:00
}
render: special case worker-count == 0 Allow render worker count to be 0, in which case the main thread renders the entire screen.
2019-08-01 20:09:39 +02:00
render: render non-block cursors after rendering the glyph + decorations This fixes an issue where an 'underline' cursor wasn't visible on underlined text - the cursor was rendered first, and then shadowed by the text underline.
2020-03-17 11:47:47 +01:00
draw_cursor:
render: use kbd-focus instead of visual focus for hollow block cursor When determining whether we should render a hollow block cursor, i.e. to signal that we're unfocused, base the decision on the terminals current keyboard focus, not visual focus.
2020-07-11 09:06:36 +02:00
if (has_cursor && (term->cursor_style != CURSOR_BLOCK || !term->kbd_focus))
render: render non-block cursors after rendering the glyph + decorations This fixes an issue where an 'underline' cursor wasn't visible on underlined text - the cursor was rendered first, and then shadowed by the text underline.
2020-03-17 11:47:47 +01:00
draw_cursor(term, cell, font, pix, &fg, &bg, x, y, cell_cols);
render: cell: reset clip region also when we're NOT rendering a glyph
2020-06-06 14:22:25 +02:00
pixman_image_set_clip_region32(pix, NULL);
render: special case worker-count == 0 Allow render worker count to be 0, in which case the main thread renders the entire screen.
2019-08-01 20:09:39 +02:00
return cell_cols;
wip: grid is now represented as a grid, not a linear array The grid is now represented with an array of row *pointers*. Each row contains an array of cells (the row's columns). The main point of having row pointers is we can now move rows around almost for free. This is useful when scrolling with scroll margins for example, where we previously had to copy the lines in the margins. Now it's just a matter of swapping two pointers.
2019-07-08 13:57:31 +02:00
}
render: use shm_scroll() when we believe it will be faster shm_scroll() is fast when memmove() is slow. That is, when scrolling a *small* amount of lines, shm_scroll() is fast. Conversely, when scrolling a *large* number of lines, memmove() is fast. For now, assume the two methods perform _roughly_ the same given a certain number of bytes they have to touch. This means we should use shm_scroll() when number of scroll lines is less than half the screen. Otherwise we use memmove. Since we need to repair the bottom scroll region after a shm_scroll, those lines are added to the count when determining which method to use. TODO: * Check if it's worth to do shm scrolling when we have a top scroll region. * Do more performance testing with a) various amount of scrolling lines, and b) larger bottom scroll regions.
2020-03-22 20:22:17 +01:00
static void
render: margins: caller explicitly asks for top/bottom margins
2020-03-23 20:14:30 +01:00
render_margin(struct terminal *term, struct buffer *buf, int start_line, int end_line,
bool top, bool bottom)
render: use shm_scroll() when we believe it will be faster shm_scroll() is fast when memmove() is slow. That is, when scrolling a *small* amount of lines, shm_scroll() is fast. Conversely, when scrolling a *large* number of lines, memmove() is fast. For now, assume the two methods perform _roughly_ the same given a certain number of bytes they have to touch. This means we should use shm_scroll() when number of scroll lines is less than half the screen. Otherwise we use memmove. Since we need to repair the bottom scroll region after a shm_scroll, those lines are added to the count when determining which method to use. TODO: * Check if it's worth to do shm scrolling when we have a top scroll region. * Do more performance testing with a) various amount of scrolling lines, and b) larger bottom scroll regions.
2020-03-22 20:22:17 +01:00
{
/* Fill area outside the cell grid with the default background color */
render: margins: caller explicitly asks for top/bottom margins
2020-03-23 20:14:30 +01:00
const int rmargin = term->width - term->margins.right;
const int bmargin = term->height - term->margins.bottom;
const int line_count = end_line - start_line;
render: use shm_scroll() when we believe it will be faster shm_scroll() is fast when memmove() is slow. That is, when scrolling a *small* amount of lines, shm_scroll() is fast. Conversely, when scrolling a *large* number of lines, memmove() is fast. For now, assume the two methods perform _roughly_ the same given a certain number of bytes they have to touch. This means we should use shm_scroll() when number of scroll lines is less than half the screen. Otherwise we use memmove. Since we need to repair the bottom scroll region after a shm_scroll, those lines are added to the count when determining which method to use. TODO: * Check if it's worth to do shm scrolling when we have a top scroll region. * Do more performance testing with a) various amount of scrolling lines, and b) larger bottom scroll regions.
2020-03-22 20:22:17 +01:00
uint32_t _bg = !term->reverse ? term->colors.bg : term->colors.fg;
render: only apply transparency to the default background color
2020-05-16 16:26:52 +02:00
pixman_color_t bg = color_hex_to_pixman_with_alpha(
_bg, _bg == term->colors.bg ? term->colors.alpha : 0xffff);
render: use shm_scroll() when we believe it will be faster shm_scroll() is fast when memmove() is slow. That is, when scrolling a *small* amount of lines, shm_scroll() is fast. Conversely, when scrolling a *large* number of lines, memmove() is fast. For now, assume the two methods perform _roughly_ the same given a certain number of bytes they have to touch. This means we should use shm_scroll() when number of scroll lines is less than half the screen. Otherwise we use memmove. Since we need to repair the bottom scroll region after a shm_scroll, those lines are added to the count when determining which method to use. TODO: * Check if it's worth to do shm scrolling when we have a top scroll region. * Do more performance testing with a) various amount of scrolling lines, and b) larger bottom scroll regions.
2020-03-22 20:22:17 +01:00
if (term->is_searching)
render: strip 'pixman' from color function names
2020-04-09 13:41:16 +02:00
color_dim(&bg);
render: use shm_scroll() when we believe it will be faster shm_scroll() is fast when memmove() is slow. That is, when scrolling a *small* amount of lines, shm_scroll() is fast. Conversely, when scrolling a *large* number of lines, memmove() is fast. For now, assume the two methods perform _roughly_ the same given a certain number of bytes they have to touch. This means we should use shm_scroll() when number of scroll lines is less than half the screen. Otherwise we use memmove. Since we need to repair the bottom scroll region after a shm_scroll, those lines are added to the count when determining which method to use. TODO: * Check if it's worth to do shm scrolling when we have a top scroll region. * Do more performance testing with a) various amount of scrolling lines, and b) larger bottom scroll regions.
2020-03-22 20:22:17 +01:00
render: margins: caller explicitly asks for top/bottom margins
2020-03-23 20:14:30 +01:00
if (top) {
render: use shm_scroll() when we believe it will be faster shm_scroll() is fast when memmove() is slow. That is, when scrolling a *small* amount of lines, shm_scroll() is fast. Conversely, when scrolling a *large* number of lines, memmove() is fast. For now, assume the two methods perform _roughly_ the same given a certain number of bytes they have to touch. This means we should use shm_scroll() when number of scroll lines is less than half the screen. Otherwise we use memmove. Since we need to repair the bottom scroll region after a shm_scroll, those lines are added to the count when determining which method to use. TODO: * Check if it's worth to do shm scrolling when we have a top scroll region. * Do more performance testing with a) various amount of scrolling lines, and b) larger bottom scroll regions.
2020-03-22 20:22:17 +01:00
pixman_image_fill_rectangles(
render: re-write cell clipping to use pixman destination clipping Our home rolled clip-to-cell code was, obviously, not correct. The original problem was that we couldn't use pixman clipping since we have multiple threads writing to the same pixman image, and thus there would be races between the threads setting clipping. The fix is actually simple - just instantiate one pixman image (referencing the same backing image data) for each rendering thread.
2020-06-04 15:39:19 +02:00
PIXMAN_OP_SRC, buf->pix[0], &bg, 1,
render: use shm_scroll() when we believe it will be faster shm_scroll() is fast when memmove() is slow. That is, when scrolling a *small* amount of lines, shm_scroll() is fast. Conversely, when scrolling a *large* number of lines, memmove() is fast. For now, assume the two methods perform _roughly_ the same given a certain number of bytes they have to touch. This means we should use shm_scroll() when number of scroll lines is less than half the screen. Otherwise we use memmove. Since we need to repair the bottom scroll region after a shm_scroll, those lines are added to the count when determining which method to use. TODO: * Check if it's worth to do shm scrolling when we have a top scroll region. * Do more performance testing with a) various amount of scrolling lines, and b) larger bottom scroll regions.
2020-03-22 20:22:17 +01:00
&(pixman_rectangle16_t){0, 0, term->width, term->margins.top});
wl_surface_damage_buffer(
term->window->surface, 0, 0, term->width, term->margins.top);
}
render: margins: caller explicitly asks for top/bottom margins
2020-03-23 20:14:30 +01:00
if (bottom) {
render: use shm_scroll() when we believe it will be faster shm_scroll() is fast when memmove() is slow. That is, when scrolling a *small* amount of lines, shm_scroll() is fast. Conversely, when scrolling a *large* number of lines, memmove() is fast. For now, assume the two methods perform _roughly_ the same given a certain number of bytes they have to touch. This means we should use shm_scroll() when number of scroll lines is less than half the screen. Otherwise we use memmove. Since we need to repair the bottom scroll region after a shm_scroll, those lines are added to the count when determining which method to use. TODO: * Check if it's worth to do shm scrolling when we have a top scroll region. * Do more performance testing with a) various amount of scrolling lines, and b) larger bottom scroll regions.
2020-03-22 20:22:17 +01:00
pixman_image_fill_rectangles(
render: re-write cell clipping to use pixman destination clipping Our home rolled clip-to-cell code was, obviously, not correct. The original problem was that we couldn't use pixman clipping since we have multiple threads writing to the same pixman image, and thus there would be races between the threads setting clipping. The fix is actually simple - just instantiate one pixman image (referencing the same backing image data) for each rendering thread.
2020-06-04 15:39:19 +02:00
PIXMAN_OP_SRC, buf->pix[0], &bg, 1,
render: use shm_scroll() when we believe it will be faster shm_scroll() is fast when memmove() is slow. That is, when scrolling a *small* amount of lines, shm_scroll() is fast. Conversely, when scrolling a *large* number of lines, memmove() is fast. For now, assume the two methods perform _roughly_ the same given a certain number of bytes they have to touch. This means we should use shm_scroll() when number of scroll lines is less than half the screen. Otherwise we use memmove. Since we need to repair the bottom scroll region after a shm_scroll, those lines are added to the count when determining which method to use. TODO: * Check if it's worth to do shm scrolling when we have a top scroll region. * Do more performance testing with a) various amount of scrolling lines, and b) larger bottom scroll regions.
2020-03-22 20:22:17 +01:00
&(pixman_rectangle16_t){0, bmargin, term->width, term->margins.bottom});
wl_surface_damage_buffer(
term->window->surface, 0, bmargin, term->width, term->margins.bottom);
}
pixman_image_fill_rectangles(
render: re-write cell clipping to use pixman destination clipping Our home rolled clip-to-cell code was, obviously, not correct. The original problem was that we couldn't use pixman clipping since we have multiple threads writing to the same pixman image, and thus there would be races between the threads setting clipping. The fix is actually simple - just instantiate one pixman image (referencing the same backing image data) for each rendering thread.
2020-06-04 15:39:19 +02:00
PIXMAN_OP_SRC, buf->pix[0], &bg, 2,
render: use shm_scroll() when we believe it will be faster shm_scroll() is fast when memmove() is slow. That is, when scrolling a *small* amount of lines, shm_scroll() is fast. Conversely, when scrolling a *large* number of lines, memmove() is fast. For now, assume the two methods perform _roughly_ the same given a certain number of bytes they have to touch. This means we should use shm_scroll() when number of scroll lines is less than half the screen. Otherwise we use memmove. Since we need to repair the bottom scroll region after a shm_scroll, those lines are added to the count when determining which method to use. TODO: * Check if it's worth to do shm scrolling when we have a top scroll region. * Do more performance testing with a) various amount of scrolling lines, and b) larger bottom scroll regions.
2020-03-22 20:22:17 +01:00
(pixman_rectangle16_t[]){
render: margins: regression: fix incorrect margins
2020-03-23 20:12:19 +01:00
/* Left */
{0, term->margins.top + start_line * term->cell_height,
term->margins.left, line_count * term->cell_height},
render: use shm_scroll() when we believe it will be faster shm_scroll() is fast when memmove() is slow. That is, when scrolling a *small* amount of lines, shm_scroll() is fast. Conversely, when scrolling a *large* number of lines, memmove() is fast. For now, assume the two methods perform _roughly_ the same given a certain number of bytes they have to touch. This means we should use shm_scroll() when number of scroll lines is less than half the screen. Otherwise we use memmove. Since we need to repair the bottom scroll region after a shm_scroll, those lines are added to the count when determining which method to use. TODO: * Check if it's worth to do shm scrolling when we have a top scroll region. * Do more performance testing with a) various amount of scrolling lines, and b) larger bottom scroll regions.
2020-03-22 20:22:17 +01:00
render: margins: regression: fix incorrect margins
2020-03-23 20:12:19 +01:00
/* Right */
{rmargin, term->margins.top + start_line * term->cell_height,
term->margins.right, line_count * term->cell_height},
});
/* Left */
render: use shm_scroll() when we believe it will be faster shm_scroll() is fast when memmove() is slow. That is, when scrolling a *small* amount of lines, shm_scroll() is fast. Conversely, when scrolling a *large* number of lines, memmove() is fast. For now, assume the two methods perform _roughly_ the same given a certain number of bytes they have to touch. This means we should use shm_scroll() when number of scroll lines is less than half the screen. Otherwise we use memmove. Since we need to repair the bottom scroll region after a shm_scroll, those lines are added to the count when determining which method to use. TODO: * Check if it's worth to do shm scrolling when we have a top scroll region. * Do more performance testing with a) various amount of scrolling lines, and b) larger bottom scroll regions.
2020-03-22 20:22:17 +01:00
wl_surface_damage_buffer(
render: margins: regression: fix incorrect margins
2020-03-23 20:12:19 +01:00
term->window->surface,
0, term->margins.top + start_line * term->cell_height,
term->margins.left, line_count * term->cell_height);
/* Right */
render: use shm_scroll() when we believe it will be faster shm_scroll() is fast when memmove() is slow. That is, when scrolling a *small* amount of lines, shm_scroll() is fast. Conversely, when scrolling a *large* number of lines, memmove() is fast. For now, assume the two methods perform _roughly_ the same given a certain number of bytes they have to touch. This means we should use shm_scroll() when number of scroll lines is less than half the screen. Otherwise we use memmove. Since we need to repair the bottom scroll region after a shm_scroll, those lines are added to the count when determining which method to use. TODO: * Check if it's worth to do shm scrolling when we have a top scroll region. * Do more performance testing with a) various amount of scrolling lines, and b) larger bottom scroll regions.
2020-03-22 20:22:17 +01:00
wl_surface_damage_buffer(
render: margins: regression: fix incorrect margins
2020-03-23 20:12:19 +01:00
term->window->surface,
rmargin, term->margins.top + start_line * term->cell_height,
term->margins.right, line_count * term->cell_height);
render: use shm_scroll() when we believe it will be faster shm_scroll() is fast when memmove() is slow. That is, when scrolling a *small* amount of lines, shm_scroll() is fast. Conversely, when scrolling a *large* number of lines, memmove() is fast. For now, assume the two methods perform _roughly_ the same given a certain number of bytes they have to touch. This means we should use shm_scroll() when number of scroll lines is less than half the screen. Otherwise we use memmove. Since we need to repair the bottom scroll region after a shm_scroll, those lines are added to the count when determining which method to use. TODO: * Check if it's worth to do shm scrolling when we have a top scroll region. * Do more performance testing with a) various amount of scrolling lines, and b) larger bottom scroll regions.
2020-03-22 20:22:17 +01:00
}
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
static void
grid_render_scroll(struct terminal *term, struct buffer *buf,
const struct damage *dmg)
{
damage: remove 'scroll' sub struct There is no other types of damage but scroll damage.
2020-04-26 12:47:19 +02:00
int height = (dmg->region.end - dmg->region.start - dmg->lines) * term->cell_height;
render: use shm_scroll() when we believe it will be faster shm_scroll() is fast when memmove() is slow. That is, when scrolling a *small* amount of lines, shm_scroll() is fast. Conversely, when scrolling a *large* number of lines, memmove() is fast. For now, assume the two methods perform _roughly_ the same given a certain number of bytes they have to touch. This means we should use shm_scroll() when number of scroll lines is less than half the screen. Otherwise we use memmove. Since we need to repair the bottom scroll region after a shm_scroll, those lines are added to the count when determining which method to use. TODO: * Check if it's worth to do shm scrolling when we have a top scroll region. * Do more performance testing with a) various amount of scrolling lines, and b) larger bottom scroll regions.
2020-03-22 20:22:17 +01:00
LOG_DBG(
"damage: SCROLL: %d-%d by %d lines",
damage: remove 'scroll' sub struct There is no other types of damage but scroll damage.
2020-04-26 12:47:19 +02:00
dmg->region.start, dmg->region.end, dmg->lines);
render: use shm_scroll() when we believe it will be faster shm_scroll() is fast when memmove() is slow. That is, when scrolling a *small* amount of lines, shm_scroll() is fast. Conversely, when scrolling a *large* number of lines, memmove() is fast. For now, assume the two methods perform _roughly_ the same given a certain number of bytes they have to touch. This means we should use shm_scroll() when number of scroll lines is less than half the screen. Otherwise we use memmove. Since we need to repair the bottom scroll region after a shm_scroll, those lines are added to the count when determining which method to use. TODO: * Check if it's worth to do shm scrolling when we have a top scroll region. * Do more performance testing with a) various amount of scrolling lines, and b) larger bottom scroll regions.
2020-03-22 20:22:17 +01:00
if (height <= 0)
return;
#if TIME_SCROLL_DAMAGE
struct timeval start_time;
gettimeofday(&start_time, NULL);
#endif
damage: remove 'scroll' sub struct There is no other types of damage but scroll damage.
2020-04-26 12:47:19 +02:00
int dst_y = term->margins.top + (dmg->region.start + 0) * term->cell_height;
int src_y = term->margins.top + (dmg->region.start + dmg->lines) * term->cell_height;
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
render: use shm_scroll() when we believe it will be faster shm_scroll() is fast when memmove() is slow. That is, when scrolling a *small* amount of lines, shm_scroll() is fast. Conversely, when scrolling a *large* number of lines, memmove() is fast. For now, assume the two methods perform _roughly_ the same given a certain number of bytes they have to touch. This means we should use shm_scroll() when number of scroll lines is less than half the screen. Otherwise we use memmove. Since we need to repair the bottom scroll region after a shm_scroll, those lines are added to the count when determining which method to use. TODO: * Check if it's worth to do shm scrolling when we have a top scroll region. * Do more performance testing with a) various amount of scrolling lines, and b) larger bottom scroll regions.
2020-03-22 20:22:17 +01:00
/*
* SHM scrolling can be *much* faster, but it depends on how many
* lines we're scrolling, and how much repairing we need to do.
*
* In short, scrolling a *large* number of rows is faster with a
* memmove, while scrolling a *small* number of lines is faster
* with SHM scrolling.
*
shm: scroll: move top/bottom region handling from renderer into shm This allows us to restore the regions without copying the contents to temporary memory.
2020-03-23 20:45:27 +01:00
* However, since we need to restore the scrolling regions when
* SHM scrolling, we also need to take this into account.
render: use shm_scroll() when we believe it will be faster shm_scroll() is fast when memmove() is slow. That is, when scrolling a *small* amount of lines, shm_scroll() is fast. Conversely, when scrolling a *large* number of lines, memmove() is fast. For now, assume the two methods perform _roughly_ the same given a certain number of bytes they have to touch. This means we should use shm_scroll() when number of scroll lines is less than half the screen. Otherwise we use memmove. Since we need to repair the bottom scroll region after a shm_scroll, those lines are added to the count when determining which method to use. TODO: * Check if it's worth to do shm scrolling when we have a top scroll region. * Do more performance testing with a) various amount of scrolling lines, and b) larger bottom scroll regions.
2020-03-22 20:22:17 +01:00
*
shm: scroll: move top/bottom region handling from renderer into shm This allows us to restore the regions without copying the contents to temporary memory.
2020-03-23 20:45:27 +01:00
* Finally, we also have to restore the window margins, and this
* is a *huge* performance hit when scrolling a large number of
* lines (in addition to the sloweness of SHM scrolling as
* method).
render: use shm_scroll() when we believe it will be faster shm_scroll() is fast when memmove() is slow. That is, when scrolling a *small* amount of lines, shm_scroll() is fast. Conversely, when scrolling a *large* number of lines, memmove() is fast. For now, assume the two methods perform _roughly_ the same given a certain number of bytes they have to touch. This means we should use shm_scroll() when number of scroll lines is less than half the screen. Otherwise we use memmove. Since we need to repair the bottom scroll region after a shm_scroll, those lines are added to the count when determining which method to use. TODO: * Check if it's worth to do shm scrolling when we have a top scroll region. * Do more performance testing with a) various amount of scrolling lines, and b) larger bottom scroll regions.
2020-03-22 20:22:17 +01:00
*
* So, we need to figure out when to SHM scroll, and when to
* memmove.
*
* For now, assume that the both methods perform rougly the same,
* given an equal number of bytes to move/allocate, and use the
* method that results in the least amount of bytes to touch.
*
* Since number of lines directly translates to bytes, we can
* simply count lines.
*
* SHM scrolling needs to first "move" (punch hole + allocate)
damage: remove 'scroll' sub struct There is no other types of damage but scroll damage.
2020-04-26 12:47:19 +02:00
* dmg->lines number of lines, and then we need to restore
render: use shm_scroll() when we believe it will be faster shm_scroll() is fast when memmove() is slow. That is, when scrolling a *small* amount of lines, shm_scroll() is fast. Conversely, when scrolling a *large* number of lines, memmove() is fast. For now, assume the two methods perform _roughly_ the same given a certain number of bytes they have to touch. This means we should use shm_scroll() when number of scroll lines is less than half the screen. Otherwise we use memmove. Since we need to repair the bottom scroll region after a shm_scroll, those lines are added to the count when determining which method to use. TODO: * Check if it's worth to do shm scrolling when we have a top scroll region. * Do more performance testing with a) various amount of scrolling lines, and b) larger bottom scroll regions.
2020-03-22 20:22:17 +01:00
* the bottom scroll region.
*
* If the total number of lines is less than half the screen - use
* SHM. Otherwise use memmove.
*/
bool try_shm_scroll =
shm: scroll: keep shm pool around, and fix its size at max allowed This lessens the burden on (primarily) the compositor, since we no longer tear down and re-create the SHM pool when scrolling. The SHM pool is setup once, and its size is fixed at the maximum allowed (512MB for now, 2GB would be possible). This also allows us to mmap() the memfd once. The exposed raw pointer is simply an offset from the memfd mmapping. Note that this means e.g. rouge rendering code will be able to write outside the buffer. Finally, only do this if the caller explicitly wants to enable scrolling. The memfd of other buffers are sized to the requested size.
2020-03-25 18:26:58 +01:00
shm_can_scroll(buf) && (
damage: remove 'scroll' sub struct There is no other types of damage but scroll damage.
2020-04-26 12:47:19 +02:00
dmg->lines +
dmg->region.start +
(term->rows - dmg->region.end)) < term->rows / 2;
render: use shm_scroll() when we believe it will be faster shm_scroll() is fast when memmove() is slow. That is, when scrolling a *small* amount of lines, shm_scroll() is fast. Conversely, when scrolling a *large* number of lines, memmove() is fast. For now, assume the two methods perform _roughly_ the same given a certain number of bytes they have to touch. This means we should use shm_scroll() when number of scroll lines is less than half the screen. Otherwise we use memmove. Since we need to repair the bottom scroll region after a shm_scroll, those lines are added to the count when determining which method to use. TODO: * Check if it's worth to do shm scrolling when we have a top scroll region. * Do more performance testing with a) various amount of scrolling lines, and b) larger bottom scroll regions.
2020-03-22 20:22:17 +01:00
bool did_shm_scroll = false;
//try_shm_scroll = false;
//try_shm_scroll = true;
if (try_shm_scroll) {
did_shm_scroll = shm_scroll(
damage: remove 'scroll' sub struct There is no other types of damage but scroll damage.
2020-04-26 12:47:19 +02:00
term->wl->shm, buf, dmg->lines * term->cell_height,
term->margins.top, dmg->region.start * term->cell_height,
term->margins.bottom, (term->rows - dmg->region.end) * term->cell_height);
render: use shm_scroll() when we believe it will be faster shm_scroll() is fast when memmove() is slow. That is, when scrolling a *small* amount of lines, shm_scroll() is fast. Conversely, when scrolling a *large* number of lines, memmove() is fast. For now, assume the two methods perform _roughly_ the same given a certain number of bytes they have to touch. This means we should use shm_scroll() when number of scroll lines is less than half the screen. Otherwise we use memmove. Since we need to repair the bottom scroll region after a shm_scroll, those lines are added to the count when determining which method to use. TODO: * Check if it's worth to do shm scrolling when we have a top scroll region. * Do more performance testing with a) various amount of scrolling lines, and b) larger bottom scroll regions.
2020-03-22 20:22:17 +01:00
}
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
render: use shm_scroll() when we believe it will be faster shm_scroll() is fast when memmove() is slow. That is, when scrolling a *small* amount of lines, shm_scroll() is fast. Conversely, when scrolling a *large* number of lines, memmove() is fast. For now, assume the two methods perform _roughly_ the same given a certain number of bytes they have to touch. This means we should use shm_scroll() when number of scroll lines is less than half the screen. Otherwise we use memmove. Since we need to repair the bottom scroll region after a shm_scroll, those lines are added to the count when determining which method to use. TODO: * Check if it's worth to do shm scrolling when we have a top scroll region. * Do more performance testing with a) various amount of scrolling lines, and b) larger bottom scroll regions.
2020-03-22 20:22:17 +01:00
if (did_shm_scroll) {
/* Restore margins */
render_margin(
damage: remove 'scroll' sub struct There is no other types of damage but scroll damage.
2020-04-26 12:47:19 +02:00
term, buf, dmg->region.end - dmg->lines, term->rows,
render: margins: caller explicitly asks for top/bottom margins
2020-03-23 20:14:30 +01:00
true, true);
shm: scroll: move top/bottom region handling from renderer into shm This allows us to restore the regions without copying the contents to temporary memory.
2020-03-23 20:45:27 +01:00
} else {
/* Fallback for when we either cannot do SHM scrolling, or it failed */
wip: render background and glyphs using pixman
2019-08-16 20:40:32 +02:00
uint8_t *raw = buf->mmapped;
memmove(raw + dst_y * buf->stride,
raw + src_y * buf->stride,
height * buf->stride);
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
}
render: use shm_scroll() when we believe it will be faster shm_scroll() is fast when memmove() is slow. That is, when scrolling a *small* amount of lines, shm_scroll() is fast. Conversely, when scrolling a *large* number of lines, memmove() is fast. For now, assume the two methods perform _roughly_ the same given a certain number of bytes they have to touch. This means we should use shm_scroll() when number of scroll lines is less than half the screen. Otherwise we use memmove. Since we need to repair the bottom scroll region after a shm_scroll, those lines are added to the count when determining which method to use. TODO: * Check if it's worth to do shm scrolling when we have a top scroll region. * Do more performance testing with a) various amount of scrolling lines, and b) larger bottom scroll regions.
2020-03-22 20:22:17 +01:00
#if TIME_SCROLL_DAMAGE
struct timeval end_time;
gettimeofday(&end_time, NULL);
struct timeval memmove_time;
timersub(&end_time, &start_time, &memmove_time);
LOG_INFO("scrolled %dKB (%d lines) using %s in %lds %ldus",
damage: remove 'scroll' sub struct There is no other types of damage but scroll damage.
2020-04-26 12:47:19 +02:00
height * buf->stride / 1024, dmg->lines,
render: use shm_scroll() when we believe it will be faster shm_scroll() is fast when memmove() is slow. That is, when scrolling a *small* amount of lines, shm_scroll() is fast. Conversely, when scrolling a *large* number of lines, memmove() is fast. For now, assume the two methods perform _roughly_ the same given a certain number of bytes they have to touch. This means we should use shm_scroll() when number of scroll lines is less than half the screen. Otherwise we use memmove. Since we need to repair the bottom scroll region after a shm_scroll, those lines are added to the count when determining which method to use. TODO: * Check if it's worth to do shm scrolling when we have a top scroll region. * Do more performance testing with a) various amount of scrolling lines, and b) larger bottom scroll regions.
2020-03-22 20:22:17 +01:00
did_shm_scroll ? "SHM" : try_shm_scroll ? "memmove (SHM failed)" : "memmove",
memmove_time.tv_sec, memmove_time.tv_usec);
#endif
wl_surface_damage_buffer(
term->window->surface, term->margins.left, dst_y,
term->width - term->margins.left - term->margins.right, height);
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
}
static void
grid_render_scroll_reverse(struct terminal *term, struct buffer *buf,
const struct damage *dmg)
{
damage: remove 'scroll' sub struct There is no other types of damage but scroll damage.
2020-04-26 12:47:19 +02:00
int height = (dmg->region.end - dmg->region.start - dmg->lines) * term->cell_height;
shm: shm_scroll(): initial implementation of reverse scrolling Implemented by truncating the file size and moving the offset backwards. This means we can only reverse scroll when we've previously scrolled forward. TODO: figure out if we can somehow do fast reverse scrolling even though offset is 0 (or well, less than required for scrolling).
2020-03-23 21:14:51 +01:00
LOG_DBG(
csi: implement CSI Ps ; Ps ; Ps t reporting escape sequences A lot of the escape sequences on the "CSI Ps ; Ps ; Ps t" form are expected to return a reply. Thus, not having these implemented means we will hang if the client sends these escapes. Not all of these escapes can be meaningfully implemented on Wayland, and thus this implementation is best effort. We now support the following escapes: * 11t - report if window is iconified (always replies "no") * 13t - report window position (always replies 0,0) * 13;2t - report text area position (replies with margins, since we cannot get the window's position) * 14t - report text area size, in pixels * 14;2t - report window size, in pixels * 15t - report screen size, in pixels * 16t - report cell size, in pixels * 18t - report text area size, in cells * 19t - report screen size, in cells
2020-04-17 23:03:20 +02:00
"damage: SCROLL REVERSE: %d-%d by %d lines",
damage: remove 'scroll' sub struct There is no other types of damage but scroll damage.
2020-04-26 12:47:19 +02:00
dmg->region.start, dmg->region.end, dmg->lines);
shm: shm_scroll(): initial implementation of reverse scrolling Implemented by truncating the file size and moving the offset backwards. This means we can only reverse scroll when we've previously scrolled forward. TODO: figure out if we can somehow do fast reverse scrolling even though offset is 0 (or well, less than required for scrolling).
2020-03-23 21:14:51 +01:00
if (height <= 0)
return;
#if TIME_SCROLL_DAMAGE
struct timeval start_time;
gettimeofday(&start_time, NULL);
#endif
damage: remove 'scroll' sub struct There is no other types of damage but scroll damage.
2020-04-26 12:47:19 +02:00
int src_y = term->margins.top + (dmg->region.start + 0) * term->cell_height;
int dst_y = term->margins.top + (dmg->region.start + dmg->lines) * term->cell_height;
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
shm: shm_scroll(): initial implementation of reverse scrolling Implemented by truncating the file size and moving the offset backwards. This means we can only reverse scroll when we've previously scrolled forward. TODO: figure out if we can somehow do fast reverse scrolling even though offset is 0 (or well, less than required for scrolling).
2020-03-23 21:14:51 +01:00
bool try_shm_scroll =
shm: scroll: keep shm pool around, and fix its size at max allowed This lessens the burden on (primarily) the compositor, since we no longer tear down and re-create the SHM pool when scrolling. The SHM pool is setup once, and its size is fixed at the maximum allowed (512MB for now, 2GB would be possible). This also allows us to mmap() the memfd once. The exposed raw pointer is simply an offset from the memfd mmapping. Note that this means e.g. rouge rendering code will be able to write outside the buffer. Finally, only do this if the caller explicitly wants to enable scrolling. The memfd of other buffers are sized to the requested size.
2020-03-25 18:26:58 +01:00
shm_can_scroll(buf) && (
damage: remove 'scroll' sub struct There is no other types of damage but scroll damage.
2020-04-26 12:47:19 +02:00
dmg->lines +
dmg->region.start +
(term->rows - dmg->region.end)) < term->rows / 2;
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
shm: shm_scroll(): initial implementation of reverse scrolling Implemented by truncating the file size and moving the offset backwards. This means we can only reverse scroll when we've previously scrolled forward. TODO: figure out if we can somehow do fast reverse scrolling even though offset is 0 (or well, less than required for scrolling).
2020-03-23 21:14:51 +01:00
bool did_shm_scroll = false;
if (try_shm_scroll) {
did_shm_scroll = shm_scroll(
damage: remove 'scroll' sub struct There is no other types of damage but scroll damage.
2020-04-26 12:47:19 +02:00
term->wl->shm, buf, -dmg->lines * term->cell_height,
term->margins.top, dmg->region.start * term->cell_height,
term->margins.bottom, (term->rows - dmg->region.end) * term->cell_height);
shm: shm_scroll(): initial implementation of reverse scrolling Implemented by truncating the file size and moving the offset backwards. This means we can only reverse scroll when we've previously scrolled forward. TODO: figure out if we can somehow do fast reverse scrolling even though offset is 0 (or well, less than required for scrolling).
2020-03-23 21:14:51 +01:00
}
if (did_shm_scroll) {
/* Restore margins */
render_margin(
damage: remove 'scroll' sub struct There is no other types of damage but scroll damage.
2020-04-26 12:47:19 +02:00
term, buf, dmg->region.start, dmg->region.start + dmg->lines,
shm: shm_scroll(): initial implementation of reverse scrolling Implemented by truncating the file size and moving the offset backwards. This means we can only reverse scroll when we've previously scrolled forward. TODO: figure out if we can somehow do fast reverse scrolling even though offset is 0 (or well, less than required for scrolling).
2020-03-23 21:14:51 +01:00
true, true);
} else {
/* Fallback for when we either cannot do SHM scrolling, or it failed */
wip: render background and glyphs using pixman
2019-08-16 20:40:32 +02:00
uint8_t *raw = buf->mmapped;
memmove(raw + dst_y * buf->stride,
raw + src_y * buf->stride,
height * buf->stride);
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
}
shm: shm_scroll(): initial implementation of reverse scrolling Implemented by truncating the file size and moving the offset backwards. This means we can only reverse scroll when we've previously scrolled forward. TODO: figure out if we can somehow do fast reverse scrolling even though offset is 0 (or well, less than required for scrolling).
2020-03-23 21:14:51 +01:00
#if TIME_SCROLL_DAMAGE
struct timeval end_time;
gettimeofday(&end_time, NULL);
struct timeval memmove_time;
timersub(&end_time, &start_time, &memmove_time);
LOG_INFO("scrolled REVERSE %dKB (%d lines) using %s in %lds %ldus",
damage: remove 'scroll' sub struct There is no other types of damage but scroll damage.
2020-04-26 12:47:19 +02:00
height * buf->stride / 1024, dmg->lines,
shm: shm_scroll(): initial implementation of reverse scrolling Implemented by truncating the file size and moving the offset backwards. This means we can only reverse scroll when we've previously scrolled forward. TODO: figure out if we can somehow do fast reverse scrolling even though offset is 0 (or well, less than required for scrolling).
2020-03-23 21:14:51 +01:00
did_shm_scroll ? "SHM" : try_shm_scroll ? "memmove (SHM failed)" : "memmove",
memmove_time.tv_sec, memmove_time.tv_usec);
#endif
wl_surface_damage_buffer(
term->window->surface, term->margins.left, dst_y,
term->width - term->margins.left - term->margins.right, height);
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
}
render: break out sixel rendering code
2020-02-21 23:48:45 +01:00
static void
sixel: calculate image height in (cell) rows
2020-02-22 00:05:25 +01:00
render_sixel(struct terminal *term, pixman_image_t *pix,
const struct sixel *sixel)
render: break out sixel rendering code
2020-02-21 23:48:45 +01:00
{
int view_end = (term->grid->view + term->rows - 1) & (term->grid->num_rows - 1);
int first_visible_row = -1;
sixel: calculate image height in (cell) rows
2020-02-22 00:05:25 +01:00
for (size_t i = sixel->pos.row; i < sixel->pos.row + sixel->rows; i++) {
int row = i & (term->grid->num_rows - 1);
if (view_end >= term->grid->view) {
/* Not wrapped */
render: break out sixel rendering code
2020-02-21 23:48:45 +01:00
if (row >= term->grid->view && row <= view_end) {
first_visible_row = i;
break;
}
sixel: calculate image height in (cell) rows
2020-02-22 00:05:25 +01:00
} else {
/* Wrapped */
render: break out sixel rendering code
2020-02-21 23:48:45 +01:00
if (row >= term->grid->view || row <= view_end) {
first_visible_row = i;
break;
}
}
}
if (first_visible_row < 0)
return;
sixel: calculate image height in (cell) rows
2020-02-22 00:05:25 +01:00
/* First visible (0 based) row of the image */
render: break out sixel rendering code
2020-02-21 23:48:45 +01:00
const int first_img_row = first_visible_row - sixel->pos.row;
sixel: calculate image height in (cell) rows
2020-02-22 00:05:25 +01:00
/* Map first visible line to current grid view */
render: break out sixel rendering code
2020-02-21 23:48:45 +01:00
const int row = first_visible_row & (term->grid->num_rows - 1);
const int view_aligned =
(row - term->grid->view + term->grid->num_rows) & (term->grid->num_rows - 1);
sixel: calculate image height in (cell) rows
2020-02-22 00:05:25 +01:00
/* Translate row/column to x/y pixel values */
term: resize: pre-calculate right/bottom margins
2020-02-24 18:38:11 +01:00
const int x = term->margins.left + sixel->pos.col * term->cell_width;
sixel: calculate image height in (cell) rows
2020-02-22 00:05:25 +01:00
const int y = max(
term: resize: pre-calculate right/bottom margins
2020-02-24 18:38:11 +01:00
term->margins.top, term->margins.top + view_aligned * term->cell_height);
render: break out sixel rendering code
2020-02-21 23:48:45 +01:00
sixel: calculate image height in (cell) rows
2020-02-22 00:05:25 +01:00
/* Width/height, in pixels - and don't touch the window margins */
term: resize: pre-calculate right/bottom margins
2020-02-24 18:38:11 +01:00
const int width = min(sixel->width, term->width - x - term->margins.right);
render: break out sixel rendering code
2020-02-21 23:48:45 +01:00
const int height = min(
sixel->height - first_img_row * term->cell_height,
term: resize: pre-calculate right/bottom margins
2020-02-24 18:38:11 +01:00
term->height - y - term->margins.bottom);
render: break out sixel rendering code
2020-02-21 23:48:45 +01:00
sixel: calculate image height in (cell) rows
2020-02-22 00:05:25 +01:00
/* Verify we're not stepping outside the grid */
term: resize: pre-calculate right/bottom margins
2020-02-24 18:38:11 +01:00
assert(x >= term->margins.left);
assert(y >= term->margins.top);
assert(x + width <= term->width - term->margins.right);
assert(y + height <= term->height - term->margins.bottom);
render: break out sixel rendering code
2020-02-21 23:48:45 +01:00
render: sixel: use pixman_image_composite32()
2020-06-06 14:22:54 +02:00
pixman_image_composite32(
render: break out sixel rendering code
2020-02-21 23:48:45 +01:00
PIXMAN_OP_SRC,
sixel->pix,
NULL,
pix,
0, first_img_row * term->cell_height,
0, 0,
x, y,
width, height);
sixel: calculate image height in (cell) rows
2020-02-22 00:05:25 +01:00
wl_surface_damage_buffer(term->window->surface, x, y, width, height);
render: break out sixel rendering code
2020-02-21 23:48:45 +01:00
}
static void
render_sixel_images(struct terminal *term, pixman_image_t *pix)
{
render: sixel: regression: need to take current offset into account when early-quitting sixel rendering The sixel images are sorted, that's true. But in order for our row numer comparisons to actually work, we need to rebase all numbers against the current scrollback offset (or, the scrollback *end*, to be precise).
2020-06-28 14:19:43 +02:00
if (likely(tll_length(term->grid->sixel_images)) == 0)
return;
const int scrollback_end
= (term->grid->offset + term->rows) & (term->grid->num_rows - 1);
const int view_start
= (term->grid->view
- scrollback_end
+ term->grid->num_rows) & (term->grid->num_rows - 1);
render: sixels: break out of loop when we're sure there aren't any more visible images The sixel list is sorted, with the most recent images *first* in the list (and thus the "oldest" images are at the back). This means we can break out of the loop when we see a sixel that *ends before* the current view starts. As a minor optimization, we also recognize sixels that *start after* the current view ends. We can't break out of the loop, but we can skip trying to render them (they wouldn't have been rendered, but more work would have been done in render_sixel() to reach this conclusion).
2020-06-28 10:45:30 +02:00
render: sixel: regression: need to take current offset into account when early-quitting sixel rendering The sixel images are sorted, that's true. But in order for our row numer comparisons to actually work, we need to rebase all numbers against the current scrollback offset (or, the scrollback *end*, to be precise).
2020-06-28 14:19:43 +02:00
const int view_end = view_start + term->rows - 1;
//LOG_DBG("SIXELS: %zu images, view=%d-%d",
// tll_length(term->grid->sixel_images), view_start, view_end);
render: sixels: break out of loop when we're sure there aren't any more visible images The sixel list is sorted, with the most recent images *first* in the list (and thus the "oldest" images are at the back). This means we can break out of the loop when we see a sixel that *ends before* the current view starts. As a minor optimization, we also recognize sixels that *start after* the current view ends. We can't break out of the loop, but we can skip trying to render them (they wouldn't have been rendered, but more work would have been done in render_sixel() to reach this conclusion).
2020-06-28 10:45:30 +02:00
tll_foreach(term->grid->sixel_images, it) {
const struct sixel *six = &it->item;
render: sixel: regression: need to take current offset into account when early-quitting sixel rendering The sixel images are sorted, that's true. But in order for our row numer comparisons to actually work, we need to rebase all numbers against the current scrollback offset (or, the scrollback *end*, to be precise).
2020-06-28 14:19:43 +02:00
const int start
= (six->pos.row
- scrollback_end
+ term->grid->num_rows) & (term->grid->num_rows - 1);
render: sixels: break out of loop when we're sure there aren't any more visible images The sixel list is sorted, with the most recent images *first* in the list (and thus the "oldest" images are at the back). This means we can break out of the loop when we see a sixel that *ends before* the current view starts. As a minor optimization, we also recognize sixels that *start after* the current view ends. We can't break out of the loop, but we can skip trying to render them (they wouldn't have been rendered, but more work would have been done in render_sixel() to reach this conclusion).
2020-06-28 10:45:30 +02:00
const int end = start + six->rows - 1;
//LOG_DBG(" sixel: %d-%d", start, end);
if (start > view_end) {
/* Sixel starts after view ends, no need to try to render it */
continue;
} else if (end < view_start) {
/* Image ends before view starts. Since the image list is
* sorted, we can safely stop here */
break;
}
render: break out sixel rendering code
2020-02-21 23:48:45 +01:00
render_sixel(term, pix, &it->item);
render: sixels: break out of loop when we're sure there aren't any more visible images The sixel list is sorted, with the most recent images *first* in the list (and thus the "oldest" images are at the back). This means we can break out of the loop when we see a sixel that *ends before* the current view starts. As a minor optimization, we also recognize sixels that *start after* the current view ends. We can't break out of the loop, but we can skip trying to render them (they wouldn't have been rendered, but more work would have been done in render_sixel() to reach this conclusion).
2020-06-28 10:45:30 +02:00
}
render: break out sixel rendering code
2020-02-21 23:48:45 +01:00
}
render: add render_row()
2019-07-24 20:31:21 +02:00
static void
render: replace all usage of cairo with pixman
2019-08-16 22:06:06 +02:00
render_row(struct terminal *term, pixman_image_t *pix, struct row *row, int row_no)
render: add render_row()
2019-07-24 20:31:21 +02:00
{
font: initial support for double-width *and* color emoji glyphs Fonts are now loaded with FT_LOAD_COLOR and we recognize and support the FT_PIXEL_MODE_BGRA pixel mode. This is mapped to a CAIRO_FORMAT_ARGB32 surface, that is blitted as-is (instead of used as a mask like we do for gray and mono glyphs). Furthermore, since many emojis are double-width, we add initial support for double-width glyphs. These are assumed to always be utf8. When PRINT:ing an utf8 character, we check its width, and add empty "spacer" cells after the cell with the multi-column glyph. When rendering, we render the columns in each row backwards. This ensures the spacer cells get cleared *before* we render the glyph (so that we don't end up erasing part of the glyph). Finally, emoji fonts are usually bitmap fonts with *large* glyphs. These aren't automatically scaled down. I.e. even if we request a glyph of 13 pixels, we might end up getting a 100px glyph. To handle this, fontconfig must be configured to scale bitmap fonts. When it is, we can look at the 'scalable' and 'pixelsizefixup' properties, and use these to scale the rendered glyph.
2019-07-31 18:03:35 +02:00
for (int col = term->cols - 1; col >= 0; col--)
render: render combining characters This is basically just a loop that renders additional glyphs on top off the base glyph. Since we now need access to the row struct, for the combining characters, the function prototype for 'render_cell()' has changed. When rendering the combining characters we also need to deal with broken fonts; some fonts use positive offsets (as if the combining character was a regular character), while others use a negative offset (to be used as if you had already advanced the pen position). We handle both - a positive offset is rendered just like a regular glyph. When we see a negative offset we simply add the width of a cell first.
2020-05-01 11:56:13 +02:00
render_cell(term, pix, row, col, row_no, false);
wip: initial multithreaded renderer
2019-07-29 20:13:26 +02:00
}
int
render_worker_thread(void *_ctx)
{
struct render_worker_context *ctx = _ctx;
struct terminal *term = ctx->term;
const int my_id = ctx->my_id;
render worker context: allocate, and let worker threads free Since we now initialize the worker threads from term_init(), which returns before the threads terminate, we can no longer use stack-allocated worker contexts. We _could_ put them in the terminal struct. But a simpler solution is to allocate them in term_init(), and let the threads free them when they don't need them anymore.
2019-10-28 18:48:43 +01:00
free(ctx);
wip: initial multithreaded renderer
2019-07-29 20:13:26 +02:00
threads: set thread titles
2019-08-01 20:09:16 +02:00
char proc_title[16];
snprintf(proc_title, sizeof(proc_title), "foot:render:%d", my_id);
if (prctl(PR_SET_NAME, proc_title, 0, 0, 0) < 0)
LOG_ERRNO("render worker %d: failed to set process title", my_id);
wip: initial multithreaded renderer
2019-07-29 20:13:26 +02:00
sem_t *start = &term->render.workers.start;
sem_t *done = &term->render.workers.done;
mtx_t *lock = &term->render.workers.lock;
cnd_t *cond = &term->render.workers.cond;
while (true) {
sem_wait(start);
struct buffer *buf = term->render.workers.buf;
bool frame_done = false;
while (!frame_done) {
mtx_lock(lock);
while (tll_length(term->render.workers.queue) == 0)
cnd_wait(cond, lock);
int row_no = tll_pop_front(term->render.workers.queue);
mtx_unlock(lock);
switch (row_no) {
default:
assert(buf != NULL);
render: re-write cell clipping to use pixman destination clipping Our home rolled clip-to-cell code was, obviously, not correct. The original problem was that we couldn't use pixman clipping since we have multiple threads writing to the same pixman image, and thus there would be races between the threads setting clipping. The fix is actually simple - just instantiate one pixman image (referencing the same backing image data) for each rendering thread.
2020-06-04 15:39:19 +02:00
render_row(term, buf->pix[my_id], grid_row_in_view(term->grid, row_no), row_no);
wip: initial multithreaded renderer
2019-07-29 20:13:26 +02:00
break;
case -1:
frame_done = true;
sem_post(done);
break;
case -2:
return 0;
}
}
};
return -1;
render: add render_row()
2019-07-24 20:31:21 +02:00
}
render: csd: split up positioning from rendering
2020-02-29 18:02:38 +01:00
struct csd_data {
int x;
int y;
int width;
int height;
};
csd: wip: something to get started...
2020-02-23 14:17:48 +01:00
render: csd: switch-based CSD positioning
2020-03-01 12:28:01 +01:00
static struct csd_data
render: csd: split up positioning from rendering
2020-02-29 18:02:38 +01:00
get_csd_data(const struct terminal *term, enum csd_surface surf_idx)
{
assert(term->window->use_csd == CSD_YES);
csd: don't draw CSDs in fullscreen mode
2020-02-26 12:39:17 +01:00
render: csd: split up positioning from rendering
2020-02-29 18:02:38 +01:00
/* Only title bar is rendered in maximized mode */
const int border_width = !term->window->is_maximized
config: make CSD user configurable The user can now configure the following: * Whether to prefer CSDs or SSDs. But note that this is only a hint to the compositor - it may deny our request. Furthermore, not all compositors implement the decoration manager protocol, meaning CSDs will be used regardless of the user configuration (GNOME/mutter being the most prominent one). * Title bar size and color, including transparency * Border size and color, including transparency Also drop support for rendering the CSDs inside the main surface.
2020-03-02 18:42:49 +01:00
? term->conf->csd.border_width * term->scale : 0;
render: CSDs: don't render borders (only title bar) in maximized mode
2020-02-28 18:49:34 +01:00
render: csd: split up positioning from rendering
2020-02-29 18:02:38 +01:00
const int title_height = !term->window->is_fullscreen
config: make CSD user configurable The user can now configure the following: * Whether to prefer CSDs or SSDs. But note that this is only a hint to the compositor - it may deny our request. Furthermore, not all compositors implement the decoration manager protocol, meaning CSDs will be used regardless of the user configuration (GNOME/mutter being the most prominent one). * Title bar size and color, including transparency * Border size and color, including transparency Also drop support for rendering the CSDs inside the main surface.
2020-03-02 18:42:49 +01:00
? term->conf->csd.title_height * term->scale : 0;
csd: position CSD sub-surfaces *outside* the main window For now, this behavior is controlled with an ifdef. At least kwin seems very buggy when the decorations are positioned like this (but normally you'd use server-side decorations with kwin anyway). This commit also changes 'use_csd' to be a tri-state variable; when instantiating a window it is set to 'unknown'. If there's no decoration manager available (e.g. weston), we immediately set it to 'yes' (use CSDs). Otherwise, we wait for the decoration manager callback to indicate whether we should use CSDs or not.
2020-02-26 12:17:58 +01:00
csd: initial implementation of minimize/maximize/close buttons
2020-03-02 20:29:28 +01:00
const int button_width = !term->window->is_fullscreen
? term->conf->csd.button_width * term->scale : 0;
render: csd: switch-based CSD positioning
2020-03-01 12:28:01 +01:00
switch (surf_idx) {
case CSD_SURF_TITLE: return (struct csd_data){ 0, -title_height, term->width, title_height};
case CSD_SURF_LEFT: return (struct csd_data){-border_width, -title_height, border_width, title_height + term->height};
case CSD_SURF_RIGHT: return (struct csd_data){ term->width, -title_height, border_width, title_height + term->height};
case CSD_SURF_TOP: return (struct csd_data){-border_width, -title_height - border_width, term->width + 2 * border_width, border_width};
case CSD_SURF_BOTTOM: return (struct csd_data){-border_width, term->height, term->width + 2 * border_width, border_width};
csd: initial implementation of minimize/maximize/close buttons
2020-03-02 20:29:28 +01:00
/* Positioned relative to CSD_SURF_TITLE */
case CSD_SURF_MINIMIZE: return (struct csd_data){term->width - 3 * button_width, 0, button_width, title_height};
case CSD_SURF_MAXIMIZE: return (struct csd_data){term->width - 2 * button_width, 0, button_width, title_height};
case CSD_SURF_CLOSE: return (struct csd_data){term->width - 1 * button_width, 0, button_width, title_height};
render: csd: switch-based CSD positioning
2020-03-01 12:28:01 +01:00
case CSD_SURF_COUNT:
assert(false);
misc: replace all explicit zero-initializers with empty initializers
2020-04-13 12:03:11 +02:00
return (struct csd_data){};
render: csd: switch-based CSD positioning
2020-03-01 12:28:01 +01:00
}
render: CSDs: don't render borders (only title bar) in maximized mode
2020-02-28 18:49:34 +01:00
render: csd: switch-based CSD positioning
2020-03-01 12:28:01 +01:00
assert(false);
misc: replace all explicit zero-initializers with empty initializers
2020-04-13 12:03:11 +02:00
return (struct csd_data){};
render: csd: split up positioning from rendering
2020-02-29 18:02:38 +01:00
}
render: CSDs: transparent borders This gives the illusion that window is border-less, but still gives us surfaces the user can grab to resize the window.
2020-02-28 18:51:09 +01:00
render: initial minimize/maximize/close glyphs These are really ugly, but is meant to get something up there, that can be polished afterwards.
2020-03-02 21:06:15 +01:00
static void
csd_commit(struct terminal *term, struct wl_surface *surf, struct buffer *buf)
{
wl_surface_attach(surf, buf->wl_buf, 0, 0);
wl_surface_damage_buffer(surf, 0, 0, buf->width, buf->height);
wl_surface_set_buffer_scale(surf, term->scale);
wl_surface_commit(surf);
}
render: csd: split up positioning from rendering
2020-02-29 18:02:38 +01:00
static void
render_csd_part(struct terminal *term,
struct wl_surface *surf, struct buffer *buf,
int width, int height, pixman_color_t *color)
{
assert(term->window->use_csd == CSD_YES);
csd: wip: something to get started...
2020-02-23 14:17:48 +01:00
render: csd: split up positioning from rendering
2020-02-29 18:02:38 +01:00
pixman_image_t *src = pixman_image_create_solid_fill(color);
csd: wip: something to get started...
2020-02-23 14:17:48 +01:00
render: csd: split up positioning from rendering
2020-02-29 18:02:38 +01:00
pixman_image_fill_rectangles(
render: re-write cell clipping to use pixman destination clipping Our home rolled clip-to-cell code was, obviously, not correct. The original problem was that we couldn't use pixman clipping since we have multiple threads writing to the same pixman image, and thus there would be races between the threads setting clipping. The fix is actually simple - just instantiate one pixman image (referencing the same backing image data) for each rendering thread.
2020-06-04 15:39:19 +02:00
PIXMAN_OP_SRC, buf->pix[0], color, 1,
render: csd: split up positioning from rendering
2020-02-29 18:02:38 +01:00
&(pixman_rectangle16_t){0, 0, buf->width, buf->height});
pixman_image_unref(src);
}
render: export render_csd()
2020-02-25 19:09:29 +01:00
render: never render CSD and/or search box "immediately" Handle the CSDs and the search box the same way we handle the main grid; when we need to redraw them, call render_refresh_{csd,search}(). This sets a flag that is checked after each FDM iteration. All actual rendering is done here. This also ties the commits of the Wayland sub-surfaces to the commit of the main surface.
2020-03-06 19:16:54 +01:00
static void
render: csd: split up positioning from rendering
2020-02-29 18:02:38 +01:00
render_csd_title(struct terminal *term)
{
render: never render CSD and/or search box "immediately" Handle the CSDs and the search box the same way we handle the main grid; when we need to redraw them, call render_refresh_{csd,search}(). This sets a flag that is checked after each FDM iteration. All actual rendering is done here. This also ties the commits of the Wayland sub-surfaces to the commit of the main surface.
2020-03-06 19:16:54 +01:00
assert(term->window->use_csd == CSD_YES);
render: don't try to render CSDs when the terminal is shutting down
2020-03-03 18:23:37 +01:00
render: csd: switch-based CSD positioning
2020-03-01 12:28:01 +01:00
struct csd_data info = get_csd_data(term, CSD_SURF_TITLE);
render: csd: split up positioning from rendering
2020-02-29 18:02:38 +01:00
struct wl_surface *surf = term->window->csd.surface[CSD_SURF_TITLE];
csd: wip: something to get started...
2020-02-23 14:17:48 +01:00
render: csd: don't try to render a zero-width/height border
2020-03-01 13:17:54 +01:00
assert(info.width > 0 && info.height > 0);
render: csd: split up positioning from rendering
2020-02-29 18:02:38 +01:00
unsigned long cookie = shm_cookie_csd(term, CSD_SURF_TITLE);
struct buffer *buf = shm_get_buffer(
render: re-write cell clipping to use pixman destination clipping Our home rolled clip-to-cell code was, obviously, not correct. The original problem was that we couldn't use pixman clipping since we have multiple threads writing to the same pixman image, and thus there would be races between the threads setting clipping. The fix is actually simple - just instantiate one pixman image (referencing the same backing image data) for each rendering thread.
2020-06-04 15:39:19 +02:00
term->wl->shm, info.width, info.height, cookie, false, 1);
csd: wip: something to get started...
2020-02-23 14:17:48 +01:00
render: CSD: use *default* foreground, not current foreground Applications may temporarily change the foreground color. Don't use this when rendering the CSD title bar - use the default foreground (i.e the default default one, or the one configured by the user in footrc).
2020-03-06 19:13:10 +01:00
uint32_t _color = term->colors.default_fg;
config: make CSD user configurable The user can now configure the following: * Whether to prefer CSDs or SSDs. But note that this is only a hint to the compositor - it may deny our request. Furthermore, not all compositors implement the decoration manager protocol, meaning CSDs will be used regardless of the user configuration (GNOME/mutter being the most prominent one). * Title bar size and color, including transparency * Border size and color, including transparency Also drop support for rendering the CSDs inside the main surface.
2020-03-02 18:42:49 +01:00
uint16_t alpha = 0xffff;
if (term->conf->csd.color.title_set) {
_color = term->conf->csd.color.title;
alpha = _color >> 24 | (_color >> 24 << 8);
}
render: export render_csd()
2020-02-25 19:09:29 +01:00
config: make CSD user configurable The user can now configure the following: * Whether to prefer CSDs or SSDs. But note that this is only a hint to the compositor - it may deny our request. Furthermore, not all compositors implement the decoration manager protocol, meaning CSDs will be used regardless of the user configuration (GNOME/mutter being the most prominent one). * Title bar size and color, including transparency * Border size and color, including transparency Also drop support for rendering the CSDs inside the main surface.
2020-03-02 18:42:49 +01:00
pixman_color_t color = color_hex_to_pixman_with_alpha(_color, alpha);
render: csd: split up positioning from rendering
2020-02-29 18:02:38 +01:00
if (!term->visual_focus)
render: strip 'pixman' from color function names
2020-04-09 13:41:16 +02:00
color_dim(&color);
render: csd: switch-based CSD positioning
2020-03-01 12:28:01 +01:00
render_csd_part(term, surf, buf, info.width, info.height, &color);
render: initial minimize/maximize/close glyphs These are really ugly, but is meant to get something up there, that can be polished afterwards.
2020-03-02 21:06:15 +01:00
csd_commit(term, surf, buf);
render: csd: split up positioning from rendering
2020-02-29 18:02:38 +01:00
}
static void
render_csd_border(struct terminal *term, enum csd_surface surf_idx)
{
render: never render CSD and/or search box "immediately" Handle the CSDs and the search box the same way we handle the main grid; when we need to redraw them, call render_refresh_{csd,search}(). This sets a flag that is checked after each FDM iteration. All actual rendering is done here. This also ties the commits of the Wayland sub-surfaces to the commit of the main surface.
2020-03-06 19:16:54 +01:00
assert(term->window->use_csd == CSD_YES);
render: csd: split up positioning from rendering
2020-02-29 18:02:38 +01:00
assert(surf_idx >= CSD_SURF_LEFT && surf_idx <= CSD_SURF_BOTTOM);
render: csd: switch-based CSD positioning
2020-03-01 12:28:01 +01:00
struct csd_data info = get_csd_data(term, surf_idx);
render: csd: split up positioning from rendering
2020-02-29 18:02:38 +01:00
struct wl_surface *surf = term->window->csd.surface[surf_idx];
render: csd: don't try to render a zero-width/height border
2020-03-01 13:17:54 +01:00
if (info.width == 0 || info.height == 0)
return;
render: csd: split up positioning from rendering
2020-02-29 18:02:38 +01:00
unsigned long cookie = shm_cookie_csd(term, surf_idx);
struct buffer *buf = shm_get_buffer(
render: re-write cell clipping to use pixman destination clipping Our home rolled clip-to-cell code was, obviously, not correct. The original problem was that we couldn't use pixman clipping since we have multiple threads writing to the same pixman image, and thus there would be races between the threads setting clipping. The fix is actually simple - just instantiate one pixman image (referencing the same backing image data) for each rendering thread.
2020-06-04 15:39:19 +02:00
term->wl->shm, info.width, info.height, cookie, false, 1);
render: csd: split up positioning from rendering
2020-02-29 18:02:38 +01:00
config: CSD borders are always invisible That is, remove all configuration options and always draw them fully transparent.
2020-03-03 18:18:59 +01:00
pixman_color_t color = color_hex_to_pixman_with_alpha(0, 0);
render: csd: switch-based CSD positioning
2020-03-01 12:28:01 +01:00
render_csd_part(term, surf, buf, info.width, info.height, &color);
render: initial minimize/maximize/close glyphs These are really ugly, but is meant to get something up there, that can be polished afterwards.
2020-03-02 21:06:15 +01:00
csd_commit(term, surf, buf);
}
static void
render_csd_button_minimize(struct terminal *term, struct buffer *buf)
{
render: csd: improved look of minimize/maximize/close buttons * minimize: a downward triangle * maximize (window): an upward triangle * maximize (already maximized): a hollow square * close: a filled square The glyphs are now rendered using the default background color instead of hardcoded to black.
2020-03-06 19:15:09 +01:00
pixman_color_t color = color_hex_to_pixman(term->colors.default_bg);
render: initial minimize/maximize/close glyphs These are really ugly, but is meant to get something up there, that can be polished afterwards.
2020-03-02 21:06:15 +01:00
pixman_image_t *src = pixman_image_create_solid_fill(&color);
render: csd: improved look of minimize/maximize/close buttons * minimize: a downward triangle * maximize (window): an upward triangle * maximize (already maximized): a hollow square * close: a filled square The glyphs are now rendered using the default background color instead of hardcoded to black.
2020-03-06 19:15:09 +01:00
const int max_height = buf->height / 2;
const int max_width = buf->width / 2;
render: initial minimize/maximize/close glyphs These are really ugly, but is meant to get something up there, that can be polished afterwards.
2020-03-02 21:06:15 +01:00
render: csd: improved look of minimize/maximize/close buttons * minimize: a downward triangle * maximize (window): an upward triangle * maximize (already maximized): a hollow square * close: a filled square The glyphs are now rendered using the default background color instead of hardcoded to black.
2020-03-06 19:15:09 +01:00
int width = max_width;
int height = max_width / 2;
if (height > max_height) {
height = max_height;
width = height * 2;
}
assert(width <= max_width);
assert(height <= max_height);
int x_margin = (buf->width - width) / 2.;
int y_margin = (buf->height - height) / 2.;
pixman_triangle_t tri = {
.p1 = {
.x = pixman_int_to_fixed(x_margin),
.y = pixman_int_to_fixed(y_margin),
},
.p2 = {
.x = pixman_int_to_fixed(x_margin + width),
.y = pixman_int_to_fixed(y_margin),
},
.p3 = {
.x = pixman_int_to_fixed(buf->width / 2),
.y = pixman_int_to_fixed(y_margin + height),
},
};
render: initial minimize/maximize/close glyphs These are really ugly, but is meant to get something up there, that can be polished afterwards.
2020-03-02 21:06:15 +01:00
render: csd: improved look of minimize/maximize/close buttons * minimize: a downward triangle * maximize (window): an upward triangle * maximize (already maximized): a hollow square * close: a filled square The glyphs are now rendered using the default background color instead of hardcoded to black.
2020-03-06 19:15:09 +01:00
pixman_composite_triangles(
render: re-write cell clipping to use pixman destination clipping Our home rolled clip-to-cell code was, obviously, not correct. The original problem was that we couldn't use pixman clipping since we have multiple threads writing to the same pixman image, and thus there would be races between the threads setting clipping. The fix is actually simple - just instantiate one pixman image (referencing the same backing image data) for each rendering thread.
2020-06-04 15:39:19 +02:00
PIXMAN_OP_OVER, src, buf->pix[0], PIXMAN_a1,
render: csd: improved look of minimize/maximize/close buttons * minimize: a downward triangle * maximize (window): an upward triangle * maximize (already maximized): a hollow square * close: a filled square The glyphs are now rendered using the default background color instead of hardcoded to black.
2020-03-06 19:15:09 +01:00
0, 0, 0, 0, 1, &tri);
render: initial minimize/maximize/close glyphs These are really ugly, but is meant to get something up there, that can be polished afterwards.
2020-03-02 21:06:15 +01:00
pixman_image_unref(src);
}
static void
render: csd: improved look of minimize/maximize/close buttons * minimize: a downward triangle * maximize (window): an upward triangle * maximize (already maximized): a hollow square * close: a filled square The glyphs are now rendered using the default background color instead of hardcoded to black.
2020-03-06 19:15:09 +01:00
render_csd_button_maximize_maximized(
struct terminal *term, struct buffer *buf)
render: initial minimize/maximize/close glyphs These are really ugly, but is meant to get something up there, that can be polished afterwards.
2020-03-02 21:06:15 +01:00
{
render: csd: improved look of minimize/maximize/close buttons * minimize: a downward triangle * maximize (window): an upward triangle * maximize (already maximized): a hollow square * close: a filled square The glyphs are now rendered using the default background color instead of hardcoded to black.
2020-03-06 19:15:09 +01:00
pixman_color_t color = color_hex_to_pixman(term->colors.default_bg);
render: initial minimize/maximize/close glyphs These are really ugly, but is meant to get something up there, that can be polished afterwards.
2020-03-02 21:06:15 +01:00
pixman_image_t *src = pixman_image_create_solid_fill(&color);
render: csd: improved look of minimize/maximize/close buttons * minimize: a downward triangle * maximize (window): an upward triangle * maximize (already maximized): a hollow square * close: a filled square The glyphs are now rendered using the default background color instead of hardcoded to black.
2020-03-06 19:15:09 +01:00
const int max_height = buf->height / 3;
const int max_width = buf->width / 3;
int width = min(max_height, max_width);
int thick = 1 * term->scale;
const int x_margin = (buf->width - width) / 2;
const int y_margin = (buf->height - width) / 2;
render: initial minimize/maximize/close glyphs These are really ugly, but is meant to get something up there, that can be polished afterwards.
2020-03-02 21:06:15 +01:00
pixman_image_fill_rectangles(
render: re-write cell clipping to use pixman destination clipping Our home rolled clip-to-cell code was, obviously, not correct. The original problem was that we couldn't use pixman clipping since we have multiple threads writing to the same pixman image, and thus there would be races between the threads setting clipping. The fix is actually simple - just instantiate one pixman image (referencing the same backing image data) for each rendering thread.
2020-06-04 15:39:19 +02:00
PIXMAN_OP_SRC, buf->pix[0], &color, 4,
render: csd: improved look of minimize/maximize/close buttons * minimize: a downward triangle * maximize (window): an upward triangle * maximize (already maximized): a hollow square * close: a filled square The glyphs are now rendered using the default background color instead of hardcoded to black.
2020-03-06 19:15:09 +01:00
(pixman_rectangle16_t[]){
{x_margin, y_margin, width, thick},
{x_margin, y_margin + thick, thick, width - 2 * thick},
{x_margin + width - thick, y_margin + thick, thick, width - 2 * thick},
{x_margin, y_margin + width - thick, width, thick}});
render: initial minimize/maximize/close glyphs These are really ugly, but is meant to get something up there, that can be polished afterwards.
2020-03-02 21:06:15 +01:00
pixman_image_unref(src);
render: csd: improved look of minimize/maximize/close buttons * minimize: a downward triangle * maximize (window): an upward triangle * maximize (already maximized): a hollow square * close: a filled square The glyphs are now rendered using the default background color instead of hardcoded to black.
2020-03-06 19:15:09 +01:00
}
static void
render_csd_button_maximize_window(
struct terminal *term, struct buffer *buf)
{
pixman_color_t color = color_hex_to_pixman(term->colors.default_bg);
pixman_image_t *src = pixman_image_create_solid_fill(&color);
const int max_height = buf->height / 2;
const int max_width = buf->width / 2;
int width = max_width;
int height = max_width / 2;
if (height > max_height) {
height = max_height;
width = height * 2;
}
assert(width <= max_width);
assert(height <= max_height);
int x_margin = (buf->width - width) / 2.;
int y_margin = (buf->height - height) / 2.;
pixman_triangle_t tri = {
.p1 = {
.x = pixman_int_to_fixed(buf->width / 2),
.y = pixman_int_to_fixed(y_margin),
},
.p2 = {
.x = pixman_int_to_fixed(x_margin),
.y = pixman_int_to_fixed(y_margin + height),
},
.p3 = {
.x = pixman_int_to_fixed(x_margin + width),
.y = pixman_int_to_fixed(y_margin + height),
},
};
pixman_composite_triangles(
render: re-write cell clipping to use pixman destination clipping Our home rolled clip-to-cell code was, obviously, not correct. The original problem was that we couldn't use pixman clipping since we have multiple threads writing to the same pixman image, and thus there would be races between the threads setting clipping. The fix is actually simple - just instantiate one pixman image (referencing the same backing image data) for each rendering thread.
2020-06-04 15:39:19 +02:00
PIXMAN_OP_OVER, src, buf->pix[0], PIXMAN_a1,
render: csd: improved look of minimize/maximize/close buttons * minimize: a downward triangle * maximize (window): an upward triangle * maximize (already maximized): a hollow square * close: a filled square The glyphs are now rendered using the default background color instead of hardcoded to black.
2020-03-06 19:15:09 +01:00
0, 0, 0, 0, 1, &tri);
pixman_image_unref(src);
}
static void
render_csd_button_maximize(struct terminal *term, struct buffer *buf)
{
if (term->window->is_maximized)
render_csd_button_maximize_maximized(term, buf);
else
render_csd_button_maximize_window(term, buf);
render: initial minimize/maximize/close glyphs These are really ugly, but is meant to get something up there, that can be polished afterwards.
2020-03-02 21:06:15 +01:00
}
static void
render_csd_button_close(struct terminal *term, struct buffer *buf)
{
render: csd: improved look of minimize/maximize/close buttons * minimize: a downward triangle * maximize (window): an upward triangle * maximize (already maximized): a hollow square * close: a filled square The glyphs are now rendered using the default background color instead of hardcoded to black.
2020-03-06 19:15:09 +01:00
pixman_color_t color = color_hex_to_pixman(term->colors.default_bg);
render: initial minimize/maximize/close glyphs These are really ugly, but is meant to get something up there, that can be polished afterwards.
2020-03-02 21:06:15 +01:00
pixman_image_t *src = pixman_image_create_solid_fill(&color);
render: csd: improved look of minimize/maximize/close buttons * minimize: a downward triangle * maximize (window): an upward triangle * maximize (already maximized): a hollow square * close: a filled square The glyphs are now rendered using the default background color instead of hardcoded to black.
2020-03-06 19:15:09 +01:00
const int max_height = buf->height / 3;
const int max_width = buf->width / 3;
int width = min(max_height, max_width);
const int x_margin = (buf->width - width) / 2;
const int y_margin = (buf->height - width) / 2;
render: initial minimize/maximize/close glyphs These are really ugly, but is meant to get something up there, that can be polished afterwards.
2020-03-02 21:06:15 +01:00
pixman_image_fill_rectangles(
render: re-write cell clipping to use pixman destination clipping Our home rolled clip-to-cell code was, obviously, not correct. The original problem was that we couldn't use pixman clipping since we have multiple threads writing to the same pixman image, and thus there would be races between the threads setting clipping. The fix is actually simple - just instantiate one pixman image (referencing the same backing image data) for each rendering thread.
2020-06-04 15:39:19 +02:00
PIXMAN_OP_SRC, buf->pix[0], &color, 1,
render: csd: improved look of minimize/maximize/close buttons * minimize: a downward triangle * maximize (window): an upward triangle * maximize (already maximized): a hollow square * close: a filled square The glyphs are now rendered using the default background color instead of hardcoded to black.
2020-03-06 19:15:09 +01:00
&(pixman_rectangle16_t){x_margin, y_margin, width, width});
render: initial minimize/maximize/close glyphs These are really ugly, but is meant to get something up there, that can be polished afterwards.
2020-03-02 21:06:15 +01:00
pixman_image_unref(src);
render: csd: split up positioning from rendering
2020-02-29 18:02:38 +01:00
}
render: never render CSD and/or search box "immediately" Handle the CSDs and the search box the same way we handle the main grid; when we need to redraw them, call render_refresh_{csd,search}(). This sets a flag that is checked after each FDM iteration. All actual rendering is done here. This also ties the commits of the Wayland sub-surfaces to the commit of the main surface.
2020-03-06 19:16:54 +01:00
static void
csd: initial implementation of minimize/maximize/close buttons
2020-03-02 20:29:28 +01:00
render_csd_button(struct terminal *term, enum csd_surface surf_idx)
{
render: never render CSD and/or search box "immediately" Handle the CSDs and the search box the same way we handle the main grid; when we need to redraw them, call render_refresh_{csd,search}(). This sets a flag that is checked after each FDM iteration. All actual rendering is done here. This also ties the commits of the Wayland sub-surfaces to the commit of the main surface.
2020-03-06 19:16:54 +01:00
assert(term->window->use_csd == CSD_YES);
assert(surf_idx >= CSD_SURF_MINIMIZE && surf_idx <= CSD_SURF_CLOSE);
render: don't try to render CSDs when the terminal is shutting down
2020-03-03 18:23:37 +01:00
csd: initial implementation of minimize/maximize/close buttons
2020-03-02 20:29:28 +01:00
struct csd_data info = get_csd_data(term, surf_idx);
struct wl_surface *surf = term->window->csd.surface[surf_idx];
if (info.width == 0 || info.height == 0)
return;
unsigned long cookie = shm_cookie_csd(term, surf_idx);
struct buffer *buf = shm_get_buffer(
render: re-write cell clipping to use pixman destination clipping Our home rolled clip-to-cell code was, obviously, not correct. The original problem was that we couldn't use pixman clipping since we have multiple threads writing to the same pixman image, and thus there would be races between the threads setting clipping. The fix is actually simple - just instantiate one pixman image (referencing the same backing image data) for each rendering thread.
2020-06-04 15:39:19 +02:00
term->wl->shm, info.width, info.height, cookie, false, 1);
csd: initial implementation of minimize/maximize/close buttons
2020-03-02 20:29:28 +01:00
uint32_t _color;
uint16_t alpha = 0xffff;
bool is_active = false;
const bool *is_set = NULL;
const uint32_t *conf_color = NULL;
switch (surf_idx) {
case CSD_SURF_MINIMIZE:
csd: buttons: use default color table as default colors If the user hasn't configured any CSD button colors, use the color scheme's default colors for blue/green/red.
2020-04-29 20:06:16 +02:00
_color = term->colors.default_table[4]; /* blue */
csd: initial implementation of minimize/maximize/close buttons
2020-03-02 20:29:28 +01:00
is_set = &term->conf->csd.color.minimize_set;
conf_color = &term->conf->csd.color.minimize;
is_active = term->active_surface == TERM_SURF_BUTTON_MINIMIZE;
break;
case CSD_SURF_MAXIMIZE:
csd: buttons: use default color table as default colors If the user hasn't configured any CSD button colors, use the color scheme's default colors for blue/green/red.
2020-04-29 20:06:16 +02:00
_color = term->colors.default_table[2]; /* green */
csd: initial implementation of minimize/maximize/close buttons
2020-03-02 20:29:28 +01:00
is_set = &term->conf->csd.color.maximize_set;
conf_color = &term->conf->csd.color.maximize;
is_active = term->active_surface == TERM_SURF_BUTTON_MAXIMIZE;
break;
case CSD_SURF_CLOSE:
csd: buttons: use default color table as default colors If the user hasn't configured any CSD button colors, use the color scheme's default colors for blue/green/red.
2020-04-29 20:06:16 +02:00
_color = term->colors.default_table[1]; /* red */
csd: initial implementation of minimize/maximize/close buttons
2020-03-02 20:29:28 +01:00
is_set = &term->conf->csd.color.close_set;
conf_color = &term->conf->csd.color.close;
is_active = term->active_surface == TERM_SURF_BUTTON_CLOSE;
break;
default:
assert(false);
break;
}
if (is_active) {
if (*is_set) {
_color = *conf_color;
alpha = _color >> 24 | (_color >> 24 << 8);
}
} else {
_color = 0;
alpha = 0;
}
pixman_color_t color = color_hex_to_pixman_with_alpha(_color, alpha);
if (!term->visual_focus)
render: strip 'pixman' from color function names
2020-04-09 13:41:16 +02:00
color_dim(&color);
csd: initial implementation of minimize/maximize/close buttons
2020-03-02 20:29:28 +01:00
render_csd_part(term, surf, buf, info.width, info.height, &color);
render: initial minimize/maximize/close glyphs These are really ugly, but is meant to get something up there, that can be polished afterwards.
2020-03-02 21:06:15 +01:00
switch (surf_idx) {
case CSD_SURF_MINIMIZE: render_csd_button_minimize(term, buf); break;
case CSD_SURF_MAXIMIZE: render_csd_button_maximize(term, buf); break;
case CSD_SURF_CLOSE: render_csd_button_close(term, buf); break;
break;
default:
assert(false);
break;
}
csd_commit(term, surf, buf);
csd: initial implementation of minimize/maximize/close buttons
2020-03-02 20:29:28 +01:00
}
render: never render CSD and/or search box "immediately" Handle the CSDs and the search box the same way we handle the main grid; when we need to redraw them, call render_refresh_{csd,search}(). This sets a flag that is checked after each FDM iteration. All actual rendering is done here. This also ties the commits of the Wayland sub-surfaces to the commit of the main surface.
2020-03-06 19:16:54 +01:00
static void
render: csd: split up positioning from rendering
2020-02-29 18:02:38 +01:00
render_csd(struct terminal *term)
{
render: never render CSD and/or search box "immediately" Handle the CSDs and the search box the same way we handle the main grid; when we need to redraw them, call render_refresh_{csd,search}(). This sets a flag that is checked after each FDM iteration. All actual rendering is done here. This also ties the commits of the Wayland sub-surfaces to the commit of the main surface.
2020-03-06 19:16:54 +01:00
assert(term->window->use_csd == CSD_YES);
render: don't try to render CSDs when the terminal is shutting down
2020-03-03 18:23:37 +01:00
render: csd: don't even try to render CSDs when we're in fullscreen mode
2020-03-03 18:23:52 +01:00
if (term->window->is_fullscreen)
return;
render: csd: split up positioning from rendering
2020-02-29 18:02:38 +01:00
for (size_t i = 0; i < CSD_SURF_COUNT; i++) {
render: csd: switch-based CSD positioning
2020-03-01 12:28:01 +01:00
struct csd_data info = get_csd_data(term, i);
const int x = info.x;
const int y = info.y;
const int width = info.width;
const int height = info.height;
render: csd: split up positioning from rendering
2020-02-29 18:02:38 +01:00
struct wl_surface *surf = term->window->csd.surface[i];
struct wl_subsurface *sub = term->window->csd.sub_surface[i];
render: csd: assert surfaces exist before trying to use them
2020-03-03 18:24:31 +01:00
assert(surf != NULL);
assert(sub != NULL);
render: csd: split up positioning from rendering
2020-02-29 18:02:38 +01:00
if (width == 0 || height == 0) {
/* CSD borders aren't rendered in maximized mode */
csd: initial implementation of minimize/maximize/close buttons
2020-03-02 20:29:28 +01:00
assert(term->window->is_maximized || term->window->is_fullscreen);
render: csd: split up positioning from rendering
2020-02-29 18:02:38 +01:00
wl_subsurface_set_position(sub, 0, 0);
wl_surface_attach(surf, NULL, 0, 0);
wl_surface_commit(surf);
continue;
}
wl_subsurface_set_position(sub, x / term->scale, y / term->scale);
csd: position CSD sub-surfaces *outside* the main window For now, this behavior is controlled with an ifdef. At least kwin seems very buggy when the decorations are positioned like this (but normally you'd use server-side decorations with kwin anyway). This commit also changes 'use_csd' to be a tri-state variable; when instantiating a window it is set to 'unknown'. If there's no decoration manager available (e.g. weston), we immediately set it to 'yes' (use CSDs). Otherwise, we wait for the decoration manager callback to indicate whether we should use CSDs or not.
2020-02-26 12:17:58 +01:00
}
render: csd: split up positioning from rendering
2020-02-29 18:02:38 +01:00
for (size_t i = CSD_SURF_LEFT; i <= CSD_SURF_BOTTOM; i++)
render_csd_border(term, i);
render: csd: render surfaces in reverse order This ensures the inner most child surfaces are rendered and comitted before the parent surfaces.
2020-03-03 18:24:51 +01:00
for (size_t i = CSD_SURF_MINIMIZE; i <= CSD_SURF_CLOSE; i++)
csd: initial implementation of minimize/maximize/close buttons
2020-03-02 20:29:28 +01:00
render_csd_button(term, i);
render: csd: render surfaces in reverse order This ensures the inner most child surfaces are rendered and comitted before the parent surfaces.
2020-03-03 18:24:51 +01:00
render_csd_title(term);
csd: wip: something to get started...
2020-02-23 14:17:48 +01:00
}
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
static void frame_callback(
void *data, struct wl_callback *wl_callback, uint32_t callback_data);
static const struct wl_callback_listener frame_listener = {
.done = &frame_callback,
};
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
static void
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
grid_render(struct terminal *term)
{
term/render: check for is_shutting_down in grid_render()
2019-12-19 07:27:14 +01:00
if (term->is_shutting_down)
return;
render: make frame rendering time measuring optional
2019-07-18 10:35:27 +02:00
#if TIME_FRAME_RENDERING
render: time how long time it takes to render a frame
2019-07-18 09:33:49 +02:00
struct timeval start_time;
gettimeofday(&start_time, NULL);
render: make frame rendering time measuring optional
2019-07-18 10:35:27 +02:00
#endif
render: time how long time it takes to render a frame
2019-07-18 09:33:49 +02:00
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
assert(term->width > 0);
assert(term->height > 0);
csd: wip: something to get started...
2020-02-23 14:17:48 +01:00
unsigned long cookie = shm_cookie_grid(term);
shm: associate a 'cookie' with each buffer When re-using a buffer from cache, only re-use ones with a matching cookie. This prevents contention between multiple terminal windows.
2019-11-02 00:33:37 +01:00
struct buffer *buf = shm_get_buffer(
render: re-write cell clipping to use pixman destination clipping Our home rolled clip-to-cell code was, obviously, not correct. The original problem was that we couldn't use pixman clipping since we have multiple threads writing to the same pixman image, and thus there would be races between the threads setting clipping. The fix is actually simple - just instantiate one pixman image (referencing the same backing image data) for each rendering thread.
2020-06-04 15:39:19 +02:00
term->wl->shm, term->width, term->height, cookie, true, 1 + term->render.workers.count);
shm: associate a 'cookie' with each buffer When re-using a buffer from cache, only re-use ones with a matching cookie. This prevents contention between multiple terminal windows.
2019-11-02 00:33:37 +01:00
render: handle compositors that does buffer swapping Not all compositors support buffer re-use. I.e. they will call the frame callback *before* the previous buffer has been released. Effectively causing us to swap between two buffers. Previously, this made us enter an infinite re-render loop, since we considered the window 'dirty' (and in need of re-draw) when the buffer is different from last redraw. Now, we detect the buffer swapping case; size must match, and we must not have any other condition that require a full repaint. In this case, we can memcpy() the old buffer to the new one, without dirtying the entire grid. We then update only the dirty cells (and scroll damage). Note that there was a bug here, where we erased the old cursor *before* checking for a new buffer. This worked when the buffer had *not* changed. Now that we need to handle the case where it *has* changed, we must do the memcpy() *before* we erase the cursor, or the re-painted cell is lost. This makes foot work on Plasma, without burning CPU. The memcpy() does incur a performance penalty, but we're still (much) faster than e.g. konsole. In fact, we're still mostly on par with Alacritty.
2019-09-27 19:33:45 +02:00
/* If we resized the window, or is flashing, or just stopped flashing */
Revert "render: last_buf may point to a free:d buffer" This reverts commit 4d3251a93b4ba309d573aca6ff397df44c4ff760.
2019-11-02 01:28:29 +01:00
if (term->render.last_buf != buf ||
render: handle compositors that does buffer swapping Not all compositors support buffer re-use. I.e. they will call the frame callback *before* the previous buffer has been released. Effectively causing us to swap between two buffers. Previously, this made us enter an infinite re-render loop, since we considered the window 'dirty' (and in need of re-draw) when the buffer is different from last redraw. Now, we detect the buffer swapping case; size must match, and we must not have any other condition that require a full repaint. In this case, we can memcpy() the old buffer to the new one, without dirtying the entire grid. We then update only the dirty cells (and scroll damage). Note that there was a bug here, where we erased the old cursor *before* checking for a new buffer. This worked when the buffer had *not* changed. Now that we need to handle the case where it *has* changed, we must do the memcpy() *before* we erase the cursor, or the re-painted cell is lost. This makes foot work on Plasma, without burning CPU. The memcpy() does incur a performance penalty, but we're still (much) faster than e.g. konsole. In fact, we're still mostly on par with Alacritty.
2019-09-27 19:33:45 +02:00
term->flash.active || term->render.was_flashing ||
term->is_searching != term->render.was_searching)
{
Revert "render: last_buf may point to a free:d buffer" This reverts commit 4d3251a93b4ba309d573aca6ff397df44c4ff760.
2019-11-02 01:28:29 +01:00
if (term->render.last_buf != NULL &&
term->render.last_buf->width == buf->width &&
term->render.last_buf->height == buf->height &&
render: handle compositors that does buffer swapping Not all compositors support buffer re-use. I.e. they will call the frame callback *before* the previous buffer has been released. Effectively causing us to swap between two buffers. Previously, this made us enter an infinite re-render loop, since we considered the window 'dirty' (and in need of re-draw) when the buffer is different from last redraw. Now, we detect the buffer swapping case; size must match, and we must not have any other condition that require a full repaint. In this case, we can memcpy() the old buffer to the new one, without dirtying the entire grid. We then update only the dirty cells (and scroll damage). Note that there was a bug here, where we erased the old cursor *before* checking for a new buffer. This worked when the buffer had *not* changed. Now that we need to handle the case where it *has* changed, we must do the memcpy() *before* we erase the cursor, or the re-painted cell is lost. This makes foot work on Plasma, without burning CPU. The memcpy() does incur a performance penalty, but we're still (much) faster than e.g. konsole. In fact, we're still mostly on par with Alacritty.
2019-09-27 19:33:45 +02:00
!term->flash.active &&
!term->render.was_flashing &&
term->is_searching == term->render.was_searching)
{
static bool has_warned = false;
if (!has_warned) {
render: use shm_scroll() when we believe it will be faster shm_scroll() is fast when memmove() is slow. That is, when scrolling a *small* amount of lines, shm_scroll() is fast. Conversely, when scrolling a *large* number of lines, memmove() is fast. For now, assume the two methods perform _roughly_ the same given a certain number of bytes they have to touch. This means we should use shm_scroll() when number of scroll lines is less than half the screen. Otherwise we use memmove. Since we need to repair the bottom scroll region after a shm_scroll, those lines are added to the count when determining which method to use. TODO: * Check if it's worth to do shm scrolling when we have a top scroll region. * Do more performance testing with a) various amount of scrolling lines, and b) larger bottom scroll regions.
2020-03-22 20:22:17 +01:00
LOG_WARN(
"it appears your Wayland compositor does not support "
"buffer re-use for SHM clients; expect lower "
"performance.");
render: handle compositors that does buffer swapping Not all compositors support buffer re-use. I.e. they will call the frame callback *before* the previous buffer has been released. Effectively causing us to swap between two buffers. Previously, this made us enter an infinite re-render loop, since we considered the window 'dirty' (and in need of re-draw) when the buffer is different from last redraw. Now, we detect the buffer swapping case; size must match, and we must not have any other condition that require a full repaint. In this case, we can memcpy() the old buffer to the new one, without dirtying the entire grid. We then update only the dirty cells (and scroll damage). Note that there was a bug here, where we erased the old cursor *before* checking for a new buffer. This worked when the buffer had *not* changed. Now that we need to handle the case where it *has* changed, we must do the memcpy() *before* we erase the cursor, or the re-painted cell is lost. This makes foot work on Plasma, without burning CPU. The memcpy() does incur a performance penalty, but we're still (much) faster than e.g. konsole. In fact, we're still mostly on par with Alacritty.
2019-09-27 19:33:45 +02:00
has_warned = true;
}
Revert "render: last_buf may point to a free:d buffer" This reverts commit 4d3251a93b4ba309d573aca6ff397df44c4ff760.
2019-11-02 01:28:29 +01:00
assert(term->render.last_buf->size == buf->size);
memcpy(buf->mmapped, term->render.last_buf->mmapped, buf->size);
render: handle compositors that does buffer swapping Not all compositors support buffer re-use. I.e. they will call the frame callback *before* the previous buffer has been released. Effectively causing us to swap between two buffers. Previously, this made us enter an infinite re-render loop, since we considered the window 'dirty' (and in need of re-draw) when the buffer is different from last redraw. Now, we detect the buffer swapping case; size must match, and we must not have any other condition that require a full repaint. In this case, we can memcpy() the old buffer to the new one, without dirtying the entire grid. We then update only the dirty cells (and scroll damage). Note that there was a bug here, where we erased the old cursor *before* checking for a new buffer. This worked when the buffer had *not* changed. Now that we need to handle the case where it *has* changed, we must do the memcpy() *before* we erase the cursor, or the re-painted cell is lost. This makes foot work on Plasma, without burning CPU. The memcpy() does incur a performance penalty, but we're still (much) faster than e.g. konsole. In fact, we're still mostly on par with Alacritty.
2019-09-27 19:33:45 +02:00
}
else {
render: clear scroll damage list when we force-refresh the entire window
2020-03-24 17:45:16 +01:00
tll_free(term->grid->scroll_damage);
render: margins: caller explicitly asks for top/bottom margins
2020-03-23 20:14:30 +01:00
render_margin(term, buf, 0, term->rows, true, true);
render: handle compositors that does buffer swapping Not all compositors support buffer re-use. I.e. they will call the frame callback *before* the previous buffer has been released. Effectively causing us to swap between two buffers. Previously, this made us enter an infinite re-render loop, since we considered the window 'dirty' (and in need of re-draw) when the buffer is different from last redraw. Now, we detect the buffer swapping case; size must match, and we must not have any other condition that require a full repaint. In this case, we can memcpy() the old buffer to the new one, without dirtying the entire grid. We then update only the dirty cells (and scroll damage). Note that there was a bug here, where we erased the old cursor *before* checking for a new buffer. This worked when the buffer had *not* changed. Now that we need to handle the case where it *has* changed, we must do the memcpy() *before* we erase the cursor, or the re-painted cell is lost. This makes foot work on Plasma, without burning CPU. The memcpy() does incur a performance penalty, but we're still (much) faster than e.g. konsole. In fact, we're still mostly on par with Alacritty.
2019-09-27 19:33:45 +02:00
term_damage_view(term);
}
Revert "render: last_buf may point to a free:d buffer" This reverts commit 4d3251a93b4ba309d573aca6ff397df44c4ff760.
2019-11-02 01:28:29 +01:00
term->render.last_buf = buf;
render: handle compositors that does buffer swapping Not all compositors support buffer re-use. I.e. they will call the frame callback *before* the previous buffer has been released. Effectively causing us to swap between two buffers. Previously, this made us enter an infinite re-render loop, since we considered the window 'dirty' (and in need of re-draw) when the buffer is different from last redraw. Now, we detect the buffer swapping case; size must match, and we must not have any other condition that require a full repaint. In this case, we can memcpy() the old buffer to the new one, without dirtying the entire grid. We then update only the dirty cells (and scroll damage). Note that there was a bug here, where we erased the old cursor *before* checking for a new buffer. This worked when the buffer had *not* changed. Now that we need to handle the case where it *has* changed, we must do the memcpy() *before* we erase the cursor, or the re-painted cell is lost. This makes foot work on Plasma, without burning CPU. The memcpy() does incur a performance penalty, but we're still (much) faster than e.g. konsole. In fact, we're still mostly on par with Alacritty.
2019-09-27 19:33:45 +02:00
term->render.was_flashing = term->flash.active;
term->render.was_searching = term->is_searching;
}
render: bug: previous cursor wasn't always redrawn correctly The main problem is knowing: * The correct *cell* (to be able to render the *content* when erasing the old cursor) * Whether the cursor has moved (to determine whether to stop the rendering loop or not) * Where on the *screen* the cursor is/was (since the terminal may be partly scrolled back) This patch stores three static variables: * last_cursor is used to compare against current cursor to see if the cursor has moved or not * last_cursor_on_screen is the actual screen coordinates the cursor was rendered at (typically the same as last_cursor, but may be offset by the view) * last_cursor_cell is a pointer to the cell to render
2019-07-24 18:15:24 +02:00
/* Erase old cursor (if we rendered a cursor last time) */
render: render combining characters This is basically just a loop that renders additional glyphs on top off the base glyph. Since we now need access to the row struct, for the combining characters, the function prototype for 'render_cell()' has changed. When rendering the combining characters we also need to deal with broken fonts; some fonts use positive offsets (as if the combining character was a regular character), while others use a negative offset (to be used as if you had already advanced the pen position). We handle both - a positive offset is rendered just like a regular glyph. When we see a negative offset we simply add the width of a cell first.
2020-05-01 11:56:13 +02:00
if (term->render.last_cursor.row != NULL) {
render: get rid of 'all-clean' detection Instead of trying to figure out if we had to render something (i.e. something in the grid was dirty), and using that to determine whether to post a callback or not, we now let render_refresh() set a flag indication we need to render another frame. This simplifies render_grid(), which now _always_ renders, and pushes it to the compositor. The callback handler checks the pending flag and simply doesn't call render_grid() when there's no more pending state to render. This ends up reducing the number of wakeups when e.g. having a blinking cursor.
2019-12-17 19:12:08 +01:00
render: render combining characters This is basically just a loop that renders additional glyphs on top off the base glyph. Since we now need access to the row struct, for the combining characters, the function prototype for 'render_cell()' has changed. When rendering the combining characters we also need to deal with broken fonts; some fonts use positive offsets (as if the combining character was a regular character), while others use a negative offset (to be used as if you had already advanced the pen position). We handle both - a positive offset is rendered just like a regular glyph. When we see a negative offset we simply add the width of a cell first.
2020-05-01 11:56:13 +02:00
struct row *row = term->render.last_cursor.row;
render: only explicitly re-render old cursor cell if it isn't dirty If it is dirty, it will be rendered in the normal rendering process.
2019-07-30 20:18:58 +02:00
struct coord at = term->render.last_cursor.in_view;
render: render combining characters This is basically just a loop that renders additional glyphs on top off the base glyph. Since we now need access to the row struct, for the combining characters, the function prototype for 'render_cell()' has changed. When rendering the combining characters we also need to deal with broken fonts; some fonts use positive offsets (as if the combining character was a regular character), while others use a negative offset (to be used as if you had already advanced the pen position). We handle both - a positive offset is rendered just like a regular glyph. When we see a negative offset we simply add the width of a cell first.
2020-05-01 11:56:13 +02:00
term->render.last_cursor.row = NULL;
struct cell *cell = &row->cells[at.col];
render: only explicitly re-render old cursor cell if it isn't dirty If it is dirty, it will be rendered in the normal rendering process.
2019-07-30 20:18:58 +02:00
render: fix bug when erasing old cursor; send correct compositor damage
2019-12-19 07:29:05 +01:00
/* If cell is already dirty, it will be rendered anyway */
render: only explicitly re-render old cursor cell if it isn't dirty If it is dirty, it will be rendered in the normal rendering process.
2019-07-30 20:18:58 +02:00
if (cell->attrs.clean) {
cell->attrs.clean = 0;
render: re-write cell clipping to use pixman destination clipping Our home rolled clip-to-cell code was, obviously, not correct. The original problem was that we couldn't use pixman clipping since we have multiple threads writing to the same pixman image, and thus there would be races between the threads setting clipping. The fix is actually simple - just instantiate one pixman image (referencing the same backing image data) for each rendering thread.
2020-06-04 15:39:19 +02:00
int cols = render_cell(term, buf->pix[0], row, at.col, at.row, false);
render: only explicitly re-render old cursor cell if it isn't dirty If it is dirty, it will be rendered in the normal rendering process.
2019-07-30 20:18:58 +02:00
wl_surface_damage_buffer(
wayland: implement wayl_init() Wayland instantiation is now done by the wayland backend, not in main.
2019-10-27 19:08:48 +01:00
term->window->surface,
term: resize: pre-calculate right/bottom margins
2020-02-24 18:38:11 +01:00
term->margins.left + at.col * term->cell_width,
term->margins.top + at.row * term->cell_height,
render: fix bug when erasing old cursor; send correct compositor damage
2019-12-19 07:29:05 +01:00
cols * term->cell_width, term->cell_height);
render: only explicitly re-render old cursor cell if it isn't dirty If it is dirty, it will be rendered in the normal rendering process.
2019-07-30 20:18:58 +02:00
}
render: regression: don't apply scroll damage when view is in scrollback When user has scrolled back in the output history, new output should not trigger scrolling. This was true for normal cell rendering, which renders the cells *in view*, not caring where the "front" of the output is. However, we still applied scroll damage. I.e. we memmoved part of the screen. The fix is simple; only apply scroll damage when the view is at the front of the output.
2019-10-28 17:58:44 +01:00
}
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
scrollback: regression: fix rendering of scrollback diffs less than a screen When doing "small" scrolls (typically done via mouse wheel or similar), we render the scrolling by emitting a "scroll damage". A recent commit changed how scroll damage is rendered; only when the view is at the bottom ("following" the screen output) do we render the damage. To fix this, add a new type of scroll damage, SCROLL_DAMAGE_IN_VIEW and SCROLL_DAMAGE_REVERSE_IN_VIEW. These signal to the renderer that it should always render the damage.
2019-10-29 21:09:37 +01:00
tll_foreach(term->grid->scroll_damage, it) {
switch (it->item.type) {
case DAMAGE_SCROLL:
if (term->grid->view == term->grid->offset)
render: regression: don't apply scroll damage when view is in scrollback When user has scrolled back in the output history, new output should not trigger scrolling. This was true for normal cell rendering, which renders the cells *in view*, not caring where the "front" of the output is. However, we still applied scroll damage. I.e. we memmoved part of the screen. The fix is simple; only apply scroll damage when the view is at the front of the output.
2019-10-28 17:58:44 +01:00
grid_render_scroll(term, buf, &it->item);
scrollback: regression: fix rendering of scrollback diffs less than a screen When doing "small" scrolls (typically done via mouse wheel or similar), we render the scrolling by emitting a "scroll damage". A recent commit changed how scroll damage is rendered; only when the view is at the bottom ("following" the screen output) do we render the damage. To fix this, add a new type of scroll damage, SCROLL_DAMAGE_IN_VIEW and SCROLL_DAMAGE_REVERSE_IN_VIEW. These signal to the renderer that it should always render the damage.
2019-10-29 21:09:37 +01:00
break;
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
scrollback: regression: fix rendering of scrollback diffs less than a screen When doing "small" scrolls (typically done via mouse wheel or similar), we render the scrolling by emitting a "scroll damage". A recent commit changed how scroll damage is rendered; only when the view is at the bottom ("following" the screen output) do we render the damage. To fix this, add a new type of scroll damage, SCROLL_DAMAGE_IN_VIEW and SCROLL_DAMAGE_REVERSE_IN_VIEW. These signal to the renderer that it should always render the damage.
2019-10-29 21:09:37 +01:00
case DAMAGE_SCROLL_REVERSE:
if (term->grid->view == term->grid->offset)
render: regression: don't apply scroll damage when view is in scrollback When user has scrolled back in the output history, new output should not trigger scrolling. This was true for normal cell rendering, which renders the cells *in view*, not caring where the "front" of the output is. However, we still applied scroll damage. I.e. we memmoved part of the screen. The fix is simple; only apply scroll damage when the view is at the front of the output.
2019-10-28 17:58:44 +01:00
grid_render_scroll_reverse(term, buf, &it->item);
scrollback: regression: fix rendering of scrollback diffs less than a screen When doing "small" scrolls (typically done via mouse wheel or similar), we render the scrolling by emitting a "scroll damage". A recent commit changed how scroll damage is rendered; only when the view is at the bottom ("following" the screen output) do we render the damage. To fix this, add a new type of scroll damage, SCROLL_DAMAGE_IN_VIEW and SCROLL_DAMAGE_REVERSE_IN_VIEW. These signal to the renderer that it should always render the damage.
2019-10-29 21:09:37 +01:00
break;
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
scrollback: regression: fix rendering of scrollback diffs less than a screen When doing "small" scrolls (typically done via mouse wheel or similar), we render the scrolling by emitting a "scroll damage". A recent commit changed how scroll damage is rendered; only when the view is at the bottom ("following" the screen output) do we render the damage. To fix this, add a new type of scroll damage, SCROLL_DAMAGE_IN_VIEW and SCROLL_DAMAGE_REVERSE_IN_VIEW. These signal to the renderer that it should always render the damage.
2019-10-29 21:09:37 +01:00
case DAMAGE_SCROLL_IN_VIEW:
grid_render_scroll(term, buf, &it->item);
break;
case DAMAGE_SCROLL_REVERSE_IN_VIEW:
grid_render_scroll_reverse(term, buf, &it->item);
break;
render: regression: don't apply scroll damage when view is in scrollback When user has scrolled back in the output history, new output should not trigger scrolling. This was true for normal cell rendering, which renders the cells *in view*, not caring where the "front" of the output is. However, we still applied scroll damage. I.e. we memmoved part of the screen. The fix is simple; only apply scroll damage when the view is at the front of the output.
2019-10-28 17:58:44 +01:00
}
scrollback: regression: fix rendering of scrollback diffs less than a screen When doing "small" scrolls (typically done via mouse wheel or similar), we render the scrolling by emitting a "scroll damage". A recent commit changed how scroll damage is rendered; only when the view is at the bottom ("following" the screen output) do we render the damage. To fix this, add a new type of scroll damage, SCROLL_DAMAGE_IN_VIEW and SCROLL_DAMAGE_REVERSE_IN_VIEW. These signal to the renderer that it should always render the damage.
2019-10-29 21:09:37 +01:00
tll_remove(term->grid->scroll_damage, it);
}
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
selection/render: sync cells' 'selected' bit before rendering For performance reasons, we track whether a cell is selected or not using a bit in a cell's attributes. This makes it easy for the renderer to determine if the cells should be rendered as selected or not - it just have to look at the 'selected' bit instead of doing a complex range check against the current selection. This works nicely in most cases. But, if the cell is updated, the 'selected' bit is cleared. This results in the renderer rendering the cell normally, i.e. _not_ selected. Checking for this, and re-setting the 'selected' bit when the cell is updated (printed to) is way too expensive as it is in the hot path. Instead, sync the 'selected' bits just before rendering. This isn't so bad as it may sound; if there is no selection this is a no-op. Even if there is a selection, only those cells whose 'selected' bit have been cleared are dirtied (and thus re-rendered) - these cells would have been re-rendered anyway.
2020-05-16 21:36:08 +02:00
/*
* Ensure selected cells have their 'selected' bit set. This is
* normally "automatically" true - the bit is set when the
* selection is made.
*
* However, if the cell is updated (printed to) while the
* selection is active, the 'selected' bit is cleared. Checking
* for this and re-setting the bit in term_print() is too
* expensive performance wise.
*
* Instead, we synchronize the selection bits here and now. This
* makes the performance impact linear to the number of selected
* cells rather than to the number of updated cells.
*
* (note that selection_dirty_cells() will not set the dirty flag
* on cells where the 'selected' bit is already set)
*/
selection_dirty_cells(term);
render: special case worker-count == 0 Allow render worker count to be 0, in which case the main thread renders the entire screen.
2019-08-01 20:09:39 +02:00
if (term->render.workers.count > 0) {
wip: initial multithreaded renderer
2019-07-29 20:13:26 +02:00
render: special case worker-count == 0 Allow render worker count to be 0, in which case the main thread renders the entire screen.
2019-08-01 20:09:39 +02:00
term->render.workers.buf = buf;
for (size_t i = 0; i < term->render.workers.count; i++)
sem_post(&term->render.workers.start);
wip: initial multithreaded renderer
2019-07-29 20:13:26 +02:00
render: special case worker-count == 0 Allow render worker count to be 0, in which case the main thread renders the entire screen.
2019-08-01 20:09:39 +02:00
assert(tll_length(term->render.workers.queue) == 0);
wip: grid is now represented as a grid, not a linear array The grid is now represented with an array of row *pointers*. Each row contains an array of cells (the row's columns). The main point of having row pointers is we can now move rows around almost for free. This is useful when scrolling with scroll margins for example, where we previously had to copy the lines in the margins. Now it's just a matter of swapping two pointers.
2019-07-08 13:57:31 +02:00
render: special case worker-count == 0 Allow render worker count to be 0, in which case the main thread renders the entire screen.
2019-08-01 20:09:39 +02:00
for (int r = 0; r < term->rows; r++) {
struct row *row = grid_row_in_view(term->grid, r);
if (!row->dirty)
continue;
mtx_lock(&term->render.workers.lock);
tll_push_back(term->render.workers.queue, r);
cnd_signal(&term->render.workers.cond);
mtx_unlock(&term->render.workers.lock);
row->dirty = false;
wl_surface_damage_buffer(
wayland: implement wayl_init() Wayland instantiation is now done by the wayland backend, not in main.
2019-10-27 19:08:48 +01:00
term->window->surface,
term: resize: pre-calculate right/bottom margins
2020-02-24 18:38:11 +01:00
term->margins.left, term->margins.top + r * term->cell_height,
term->width - term->margins.left - term->margins.right, term->cell_height);
render: special case worker-count == 0 Allow render worker count to be 0, in which case the main thread renders the entire screen.
2019-08-01 20:09:39 +02:00
}
wip: grid is now represented as a grid, not a linear array The grid is now represented with an array of row *pointers*. Each row contains an array of cells (the row's columns). The main point of having row pointers is we can now move rows around almost for free. This is useful when scrolling with scroll margins for example, where we previously had to copy the lines in the margins. Now it's just a matter of swapping two pointers.
2019-07-08 13:57:31 +02:00
wip: initial multithreaded renderer
2019-07-29 20:13:26 +02:00
mtx_lock(&term->render.workers.lock);
render: special case worker-count == 0 Allow render worker count to be 0, in which case the main thread renders the entire screen.
2019-08-01 20:09:39 +02:00
for (size_t i = 0; i < term->render.workers.count; i++)
tll_push_back(term->render.workers.queue, -1);
cnd_broadcast(&term->render.workers.cond);
wip: initial multithreaded renderer
2019-07-29 20:13:26 +02:00
mtx_unlock(&term->render.workers.lock);
render: special case worker-count == 0 Allow render worker count to be 0, in which case the main thread renders the entire screen.
2019-08-01 20:09:39 +02:00
} else {
for (int r = 0; r < term->rows; r++) {
struct row *row = grid_row_in_view(term->grid, r);
wip: grid is now represented as a grid, not a linear array The grid is now represented with an array of row *pointers*. Each row contains an array of cells (the row's columns). The main point of having row pointers is we can now move rows around almost for free. This is useful when scrolling with scroll margins for example, where we previously had to copy the lines in the margins. Now it's just a matter of swapping two pointers.
2019-07-08 13:57:31 +02:00
render: special case worker-count == 0 Allow render worker count to be 0, in which case the main thread renders the entire screen.
2019-08-01 20:09:39 +02:00
if (!row->dirty)
continue;
wip: grid is now represented as a grid, not a linear array The grid is now represented with an array of row *pointers*. Each row contains an array of cells (the row's columns). The main point of having row pointers is we can now move rows around almost for free. This is useful when scrolling with scroll margins for example, where we previously had to copy the lines in the margins. Now it's just a matter of swapping two pointers.
2019-07-08 13:57:31 +02:00
render: re-write cell clipping to use pixman destination clipping Our home rolled clip-to-cell code was, obviously, not correct. The original problem was that we couldn't use pixman clipping since we have multiple threads writing to the same pixman image, and thus there would be races between the threads setting clipping. The fix is actually simple - just instantiate one pixman image (referencing the same backing image data) for each rendering thread.
2020-06-04 15:39:19 +02:00
render_row(term, buf->pix[0], row, r);
render: special case worker-count == 0 Allow render worker count to be 0, in which case the main thread renders the entire screen.
2019-08-01 20:09:39 +02:00
row->dirty = false;
wl_surface_damage_buffer(
wayland: implement wayl_init() Wayland instantiation is now done by the wayland backend, not in main.
2019-10-27 19:08:48 +01:00
term->window->surface,
term: resize: pre-calculate right/bottom margins
2020-02-24 18:38:11 +01:00
term->margins.left, term->margins.top + r * term->cell_height,
term->width - term->margins.left - term->margins.right, term->cell_height);
render: special case worker-count == 0 Allow render worker count to be 0, in which case the main thread renders the entire screen.
2019-08-01 20:09:39 +02:00
}
}
wip: initial multithreaded renderer
2019-07-29 20:13:26 +02:00
render: bug: previous cursor wasn't always redrawn correctly The main problem is knowing: * The correct *cell* (to be able to render the *content* when erasing the old cursor) * Whether the cursor has moved (to determine whether to stop the rendering loop or not) * Where on the *screen* the cursor is/was (since the terminal may be partly scrolled back) This patch stores three static variables: * last_cursor is used to compare against current cursor to see if the cursor has moved or not * last_cursor_on_screen is the actual screen coordinates the cursor was rendered at (typically the same as last_cursor, but may be offset by the view) * last_cursor_cell is a pointer to the cell to render
2019-07-24 18:15:24 +02:00
/*
* Determine if we need to render a cursor or not. The cursor
* could be hidden. Or it could have been scrolled out of view.
*/
render: don't render cursor if it is not in view
2019-07-10 09:51:42 +02:00
bool cursor_is_visible = false;
scrolling: optimize row access by assuming number of rows is a power of 2 With this assumption, we can replace 'a % b' with 'a & (b - 1)'. In terms of instructions, this means a fast 'and' instead of a slow 'div'. Further optimize scrolling by: * not double-initializing empty rows. Previously, grid_row_alloc() called calloc(), which was then followed by a memset() when scrolling. This is of course unnecessary. * Don't loop the entire set of visible rows (this was done to ensure all visible rows had been allocated, and to prefetch the cell contents). This isn't necessary; only newly pulled in rows can be NULL. For now, don't prefetch at all.
2019-08-22 17:33:23 +02:00
int view_end = (term->grid->view + term->rows - 1) & (term->grid->num_rows - 1);
grid: move 'cursor' state from terminal to grid This way, the 'normal' and 'alt' grids have their own cursor state, and we don't need to switch between them.
2020-04-16 18:51:14 +02:00
int cursor_row = (term->grid->offset + term->grid->cursor.point.row) & (term->grid->num_rows - 1);
render: don't render cursor if it is not in view
2019-07-10 09:51:42 +02:00
if (view_end >= term->grid->view) {
/* Not wrapped */
if (cursor_row >= term->grid->view && cursor_row <= view_end)
cursor_is_visible = true;
} else {
/* Wrapped */
if (cursor_row >= term->grid->view || cursor_row <= view_end)
cursor_is_visible = true;
}
wip: grid is now represented as a grid, not a linear array The grid is now represented with an array of row *pointers*. Each row contains an array of cells (the row's columns). The main point of having row pointers is we can now move rows around almost for free. This is useful when scrolling with scroll margins for example, where we previously had to copy the lines in the margins. Now it's just a matter of swapping two pointers.
2019-07-08 13:57:31 +02:00
render: special case worker-count == 0 Allow render worker count to be 0, in which case the main thread renders the entire screen.
2019-08-01 20:09:39 +02:00
/*
* Wait for workers to finish before we render the cursor. This is
* because the cursor cell might be dirty, in which case a worker
* will render it (but without the cursor).
*/
if (term->render.workers.count > 0) {
for (size_t i = 0; i < term->render.workers.count; i++)
sem_wait(&term->render.workers.done);
term->render.workers.buf = NULL;
}
wip: initial multithreaded renderer
2019-07-29 20:13:26 +02:00
render: bug: don't render cursor when hide cursor is enabled
2019-07-11 09:59:51 +02:00
if (cursor_is_visible && !term->hide_cursor) {
render: bug: previous cursor wasn't always redrawn correctly The main problem is knowing: * The correct *cell* (to be able to render the *content* when erasing the old cursor) * Whether the cursor has moved (to determine whether to stop the rendering loop or not) * Where on the *screen* the cursor is/was (since the terminal may be partly scrolled back) This patch stores three static variables: * last_cursor is used to compare against current cursor to see if the cursor has moved or not * last_cursor_on_screen is the actual screen coordinates the cursor was rendered at (typically the same as last_cursor, but may be offset by the view) * last_cursor_cell is a pointer to the cell to render
2019-07-24 18:15:24 +02:00
/* Remember cursor coordinates so that we can erase it next
* time. Note that we need to re-align it against the view. */
render: move local static variables into the terminal struct
2019-07-24 20:21:41 +02:00
int view_aligned_row
scrolling: optimize row access by assuming number of rows is a power of 2 With this assumption, we can replace 'a % b' with 'a & (b - 1)'. In terms of instructions, this means a fast 'and' instead of a slow 'div'. Further optimize scrolling by: * not double-initializing empty rows. Previously, grid_row_alloc() called calloc(), which was then followed by a memset() when scrolling. This is of course unnecessary. * Don't loop the entire set of visible rows (this was done to ensure all visible rows had been allocated, and to prefetch the cell contents). This isn't necessary; only newly pulled in rows can be NULL. For now, don't prefetch at all.
2019-08-22 17:33:23 +02:00
= (cursor_row - term->grid->view + term->grid->num_rows) & (term->grid->num_rows - 1);
render: bug: previous cursor wasn't always redrawn correctly The main problem is knowing: * The correct *cell* (to be able to render the *content* when erasing the old cursor) * Whether the cursor has moved (to determine whether to stop the rendering loop or not) * Where on the *screen* the cursor is/was (since the terminal may be partly scrolled back) This patch stores three static variables: * last_cursor is used to compare against current cursor to see if the cursor has moved or not * last_cursor_on_screen is the actual screen coordinates the cursor was rendered at (typically the same as last_cursor, but may be offset by the view) * last_cursor_cell is a pointer to the cell to render
2019-07-24 18:15:24 +02:00
grid: move 'cursor' state from terminal to grid This way, the 'normal' and 'alt' grids have their own cursor state, and we don't need to switch between them.
2020-04-16 18:51:14 +02:00
term->render.last_cursor.actual = term->grid->cursor.point;
render: move local static variables into the terminal struct
2019-07-24 20:21:41 +02:00
term->render.last_cursor.in_view = (struct coord) {
grid: move 'cursor' state from terminal to grid This way, the 'normal' and 'alt' grids have their own cursor state, and we don't need to switch between them.
2020-04-16 18:51:14 +02:00
term->grid->cursor.point.col, view_aligned_row};
render: bug: previous cursor wasn't always redrawn correctly The main problem is knowing: * The correct *cell* (to be able to render the *content* when erasing the old cursor) * Whether the cursor has moved (to determine whether to stop the rendering loop or not) * Where on the *screen* the cursor is/was (since the terminal may be partly scrolled back) This patch stores three static variables: * last_cursor is used to compare against current cursor to see if the cursor has moved or not * last_cursor_on_screen is the actual screen coordinates the cursor was rendered at (typically the same as last_cursor, but may be offset by the view) * last_cursor_cell is a pointer to the cell to render
2019-07-24 18:15:24 +02:00
render: move local static variables into the terminal struct
2019-07-24 20:21:41 +02:00
struct row *row = grid_row_in_view(term->grid, view_aligned_row);
grid: move 'cursor' state from terminal to grid This way, the 'normal' and 'alt' grids have their own cursor state, and we don't need to switch between them.
2020-04-16 18:51:14 +02:00
struct cell *cell = &row->cells[term->grid->cursor.point.col];
render: move local static variables into the terminal struct
2019-07-24 20:21:41 +02:00
font: add support for fallback fonts A top-level font now has a list of fallback fonts. When a glyph cannot be found, we try each fallback font in turn, until we either find one that has the glyph, or until we've exhausted the list. To make this actually work in practise (read: to make performance acceptable), the cache is re-worked and is now populated on demand. It also supports non-ASCII characters, by using the 4-byte unicode character as index instead. Since having an array that can be indexed by a 4-byte value isn't really viable, we now have a simple hash table instead of an array.
2019-07-30 18:04:28 +02:00
cell->attrs.clean = 0;
render: render combining characters This is basically just a loop that renders additional glyphs on top off the base glyph. Since we now need access to the row struct, for the combining characters, the function prototype for 'render_cell()' has changed. When rendering the combining characters we also need to deal with broken fonts; some fonts use positive offsets (as if the combining character was a regular character), while others use a negative offset (to be used as if you had already advanced the pen position). We handle both - a positive offset is rendered just like a regular glyph. When we see a negative offset we simply add the width of a cell first.
2020-05-01 11:56:13 +02:00
term->render.last_cursor.row = row;
render: special case worker-count == 0 Allow render worker count to be 0, in which case the main thread renders the entire screen.
2019-08-01 20:09:39 +02:00
int cols_updated = render_cell(
render: re-write cell clipping to use pixman destination clipping Our home rolled clip-to-cell code was, obviously, not correct. The original problem was that we couldn't use pixman clipping since we have multiple threads writing to the same pixman image, and thus there would be races between the threads setting clipping. The fix is actually simple - just instantiate one pixman image (referencing the same backing image data) for each rendering thread.
2020-06-04 15:39:19 +02:00
term, buf->pix[0], row, term->grid->cursor.point.col, view_aligned_row, true);
render: don't render cursor if it is not in view
2019-07-10 09:51:42 +02:00
wl_surface_damage_buffer(
wayland: implement wayl_init() Wayland instantiation is now done by the wayland backend, not in main.
2019-10-27 19:08:48 +01:00
term->window->surface,
grid: move 'cursor' state from terminal to grid This way, the 'normal' and 'alt' grids have their own cursor state, and we don't need to switch between them.
2020-04-16 18:51:14 +02:00
term->margins.left + term->grid->cursor.point.col * term->cell_width,
term: resize: pre-calculate right/bottom margins
2020-02-24 18:38:11 +01:00
term->margins.top + view_aligned_row * term->cell_height,
render: special case worker-count == 0 Allow render worker count to be 0, in which case the main thread renders the entire screen.
2019-08-01 20:09:39 +02:00
cols_updated * term->cell_width, term->cell_height);
render: don't render cursor if it is not in view
2019-07-10 09:51:42 +02:00
}
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
render: re-write cell clipping to use pixman destination clipping Our home rolled clip-to-cell code was, obviously, not correct. The original problem was that we couldn't use pixman clipping since we have multiple threads writing to the same pixman image, and thus there would be races between the threads setting clipping. The fix is actually simple - just instantiate one pixman image (referencing the same backing image data) for each rendering thread.
2020-06-04 15:39:19 +02:00
render_sixel_images(term, buf->pix[0]);
sixel: initial support This implements basic parsing of sixel data. Lots of limitations and temporary solutions as this is still work-in-progress: * Maximum image size hardcoded to 800x800 * No HLS color format support * Image is always rendered at 0x0 in the terminal
2020-02-21 21:53:23 +01:00
term: group 'flash' state together in a struct
2019-07-22 19:15:56 +02:00
if (term->flash.active) {
render: replace all usage of cairo with pixman
2019-08-16 22:06:06 +02:00
/* Note: alpha is pre-computed in each color component */
search: wip: re-direct input while searching, and build a search buffer This adds a new state, 'is_searching'. While active, input is re-directed, and stored in a search buffer. In the future, we'll use this buffer and search for its content in the scrollback buffer, and move the view and create a selection on matches. When rendering in 'is_searching', everything is dimmed. In the future, we'll render the current search buffer on-top of the dimmed "regular" terminal output.
2019-08-27 17:23:28 +02:00
/* TODO: dim while searching */
render: replace all usage of cairo with pixman
2019-08-16 22:06:06 +02:00
pixman_image_fill_rectangles(
render: re-write cell clipping to use pixman destination clipping Our home rolled clip-to-cell code was, obviously, not correct. The original problem was that we couldn't use pixman clipping since we have multiple threads writing to the same pixman image, and thus there would be races between the threads setting clipping. The fix is actually simple - just instantiate one pixman image (referencing the same backing image data) for each rendering thread.
2020-06-04 15:39:19 +02:00
PIXMAN_OP_OVER, buf->pix[0],
render: replace all usage of cairo with pixman
2019-08-16 22:06:06 +02:00
&(pixman_color_t){.red=0x7fff, .green=0x7fff, .blue=0, .alpha=0x7fff},
1, &(pixman_rectangle16_t){0, 0, term->width, term->height});
flash: implement 'flash' Use our own escape sequence for the 'flash' terminfo entry. Implemented by arming a timer FD and setting a boolean that indicates we're currently "flashing". The renderer draws a semi-transparent yellowish layer over the entire window when "flashing" is active.
2019-07-21 19:14:19 +02:00
wl_surface_damage_buffer(
wayland: implement wayl_init() Wayland instantiation is now done by the wayland backend, not in main.
2019-10-27 19:08:48 +01:00
term->window->surface, 0, 0, term->width, term->height);
flash: implement 'flash' Use our own escape sequence for the 'flash' terminfo entry. Implemented by arming a timer FD and setting a boolean that indicates we're currently "flashing". The renderer draws a semi-transparent yellowish layer over the entire window when "flashing" is active.
2019-07-21 19:14:19 +02:00
}
render: use pointers to rgba foreground/background colors This is faster, since we don't have to copy several large doubles when swapping the colors.
2019-07-08 15:27:44 +02:00
assert(term->grid->offset >= 0 && term->grid->offset < term->grid->num_rows);
wip: initial scroll back support Can scroll up and down, and stops when the beginning/end of history is reached. However, it probably breaks when the entire scrollback buffer has been filled - we need to detect when the view has wrapped around to the current terminal offset. The detection of when we've reached the bottom of the history is also flawed, and only works when we overshoot the bottom with at least a page. Resizing the windows while in a view most likely doesn't work. The view will not detect a wrapped around scrollback buffer. I.e. if the user has scrolled back, and is stationary at a view, but there is still output being produced. Then eventually the scrollback buffer will wrap around. In this case, the correct thing to do is make the view start following the beginning of the history. Right now it doesn't, meaning once the scrollback buffer wraps around, you'll start seeing command output...
2019-07-09 16:26:36 +02:00
assert(term->grid->view >= 0 && term->grid->view < term->grid->num_rows);
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
wayland: implement wayl_init() Wayland instantiation is now done by the wayland backend, not in main.
2019-10-27 19:08:48 +01:00
assert(term->window->frame_callback == NULL);
term->window->frame_callback = wl_surface_frame(term->window->surface);
wl_callback_add_listener(term->window->frame_callback, &frame_listener, term);
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
wayland: implement wayl_init() Wayland instantiation is now done by the wayland backend, not in main.
2019-10-27 19:08:48 +01:00
wl_surface_set_buffer_scale(term->window->surface, term->scale);
wayland: optionally use the presentation time protocol to measure input lag 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.
2019-12-31 15:39:40 +01:00
if (term->wl->presentation != NULL && term->render.presentation_timings) {
presentation: store input timestamp in a per-commit context This should reduce the risk of mixing up an input timestamp with the corresponding rendered frame.
2020-01-21 18:51:04 +01:00
struct timespec commit_time;
clock_gettime(term->wl->presentation_clock_id, &commit_time);
wayland: optionally use the presentation time protocol to measure input lag 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.
2019-12-31 15:39:40 +01:00
struct wp_presentation_feedback *feedback = wp_presentation_feedback(
term->wl->presentation, term->window->surface);
if (feedback == NULL) {
LOG_WARN("failed to create presentation feedback");
} else {
presentation: store input timestamp in a per-commit context This should reduce the risk of mixing up an input timestamp with the corresponding rendered frame.
2020-01-21 18:51:04 +01:00
struct presentation_context *ctx = malloc(sizeof(*ctx));
*ctx = (struct presentation_context){
.term = term,
.input.tv_sec = term->render.input_time.tv_sec,
.input.tv_usec = term->render.input_time.tv_nsec / 1000,
.commit.tv_sec = commit_time.tv_sec,
.commit.tv_usec = commit_time.tv_nsec / 1000,
};
wayland: optionally use the presentation time protocol to measure input lag 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.
2019-12-31 15:39:40 +01:00
wp_presentation_feedback_add_listener(
presentation: store input timestamp in a per-commit context This should reduce the risk of mixing up an input timestamp with the corresponding rendered frame.
2020-01-21 18:51:04 +01:00
feedback, &presentation_feedback_listener, ctx);
term->render.input_time.tv_sec = 0;
term->render.input_time.tv_nsec = 0;
wayland: optionally use the presentation time protocol to measure input lag 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.
2019-12-31 15:39:40 +01:00
}
}
render: attach buffer just before commit
2020-03-24 17:45:38 +01:00
wl_surface_attach(term->window->surface, buf->wl_buf, 0, 0);
quirk_kde_damage_before_attach(term->window->surface);
wayland: implement wayl_init() Wayland instantiation is now done by the wayland backend, not in main.
2019-10-27 19:08:48 +01:00
wl_surface_commit(term->window->surface);
render: time how long time it takes to render a frame
2019-07-18 09:33:49 +02:00
render: make frame rendering time measuring optional
2019-07-18 10:35:27 +02:00
#if TIME_FRAME_RENDERING
render: time how long time it takes to render a frame
2019-07-18 09:33:49 +02:00
struct timeval end_time;
gettimeofday(&end_time, NULL);
struct timeval render_time;
timersub(&end_time, &start_time, &render_time);
render: log frame rendering time with microseconds instead of milliseconds
2019-08-24 11:32:28 +02:00
LOG_INFO("frame rendered in %lds %ldus",
render_time.tv_sec, render_time.tv_usec);
render: make frame rendering time measuring optional
2019-07-18 10:35:27 +02:00
#endif
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
}
static void
search: move render() function to the 'render' module
2019-08-29 20:18:06 +02:00
render_search_box(struct terminal *term)
{
wayland: implement wayl_init() Wayland instantiation is now done by the wayland backend, not in main.
2019-10-27 19:08:48 +01:00
assert(term->window->search_sub_surface != NULL);
search: move render() function to the 'render' module
2019-08-29 20:18:06 +02:00
render: ensure cursor is always visible in the search box Maintain a view 'offset' (which glyph from the search string to start rendering at). This defines the start of the viewable area. The end is the offset + the search box size (which is limited to the window size). Adjust this offset whenever the cursor moves outside the viewable area. For now, this is always done in the same way: set the offset to the cursor position. This means that when we're entering text at the end of the search criteria (i.e. the normal case; we're simply typing), and the search box reaches the window size, the cursor will jump to the start of the search box, which will be empty. This could be confusing, but let's go with for now.
2020-01-05 15:16:40 +01:00
const size_t wanted_visible_chars = max(20, term->search.len);
render: search: take CSD into account
2020-02-25 20:30:45 +01:00
assert(term->scale >= 1);
const int scale = term->scale;
config: make CSD user configurable The user can now configure the following: * Whether to prefer CSDs or SSDs. But note that this is only a hint to the compositor - it may deny our request. Furthermore, not all compositors implement the decoration manager protocol, meaning CSDs will be used regardless of the user configuration (GNOME/mutter being the most prominent one). * Title bar size and color, including transparency * Border size and color, including transparency Also drop support for rendering the CSDs inside the main surface.
2020-03-02 18:42:49 +01:00
const size_t margin = 3 * scale;
render: ensure cursor is always visible in the search box Maintain a view 'offset' (which glyph from the search string to start rendering at). This defines the start of the viewable area. The end is the offset + the search box size (which is limited to the window size). Adjust this offset whenever the cursor moves outside the viewable area. For now, this is always done in the same way: set the offset to the cursor position. This means that when we're entering text at the end of the search criteria (i.e. the normal case; we're simply typing), and the search box reaches the window size, the cursor will jump to the start of the search box, which will be empty. This could be confusing, but let's go with for now.
2020-01-05 15:16:40 +01:00
render: search: kwin has problems with a resizing/repositioned sub-surface So, make it equal to the window size, and make the non-used area fully transparent.
2020-03-01 12:28:33 +01:00
const size_t width = term->width - 2 * margin;
const size_t visible_width = min(
render: ensure cursor is always visible in the search box Maintain a view 'offset' (which glyph from the search string to start rendering at). This defines the start of the viewable area. The end is the offset + the search box size (which is limited to the window size). Adjust this offset whenever the cursor moves outside the viewable area. For now, this is always done in the same way: set the offset to the cursor position. This means that when we're entering text at the end of the search criteria (i.e. the normal case; we're simply typing), and the search box reaches the window size, the cursor will jump to the start of the search box, which will be empty. This could be confusing, but let's go with for now.
2020-01-05 15:16:40 +01:00
term->width - 2 * margin,
2 * margin + wanted_visible_chars * term->cell_width);
const size_t height = min(
term->height - 2 * margin,
2 * margin + 1 * term->cell_height);
render: search: kwin has problems with a resizing/repositioned sub-surface So, make it equal to the window size, and make the non-used area fully transparent.
2020-03-01 12:28:33 +01:00
const size_t visible_chars = (visible_width - 2 * margin) / term->cell_width;
search: rename render.search_offset -> render.search_glyph_offset
2020-01-05 15:25:24 +01:00
size_t glyph_offset = term->render.search_glyph_offset;
search: move render() function to the 'render' module
2019-08-29 20:18:06 +02:00
csd: wip: something to get started...
2020-02-23 14:17:48 +01:00
unsigned long cookie = shm_cookie_search(term);
render: re-write cell clipping to use pixman destination clipping Our home rolled clip-to-cell code was, obviously, not correct. The original problem was that we couldn't use pixman clipping since we have multiple threads writing to the same pixman image, and thus there would be races between the threads setting clipping. The fix is actually simple - just instantiate one pixman image (referencing the same backing image data) for each rendering thread.
2020-06-04 15:39:19 +02:00
struct buffer *buf = shm_get_buffer(term->wl->shm, width, height, cookie, false, 1);
search: move render() function to the 'render' module
2019-08-29 20:18:06 +02:00
/* Background - yellow on empty/match, red on mismatch */
pixman_color_t color = color_hex_to_pixman(
render: search box: use colors from the color table Use the 'yellow' color from the 'regular' range of colors (SGR 33) for background when we have a match, or 'red' from the 'regular' range of colors (SGR 31) when we don't have a match. Foreground uses the 'black' color from the regular range of colors (SGR 30).
2019-08-30 21:01:13 +02:00
term->search.match_len == term->search.len
? term->colors.table[3] : term->colors.table[1]);
search: move render() function to the 'render' module
2019-08-29 20:18:06 +02:00
pixman_image_fill_rectangles(
render: re-write cell clipping to use pixman destination clipping Our home rolled clip-to-cell code was, obviously, not correct. The original problem was that we couldn't use pixman clipping since we have multiple threads writing to the same pixman image, and thus there would be races between the threads setting clipping. The fix is actually simple - just instantiate one pixman image (referencing the same backing image data) for each rendering thread.
2020-06-04 15:39:19 +02:00
PIXMAN_OP_SRC, buf->pix[0], &color,
render: search: kwin has problems with a resizing/repositioned sub-surface So, make it equal to the window size, and make the non-used area fully transparent.
2020-03-01 12:28:33 +01:00
1, &(pixman_rectangle16_t){width - visible_width, 0, visible_width, height});
pixman_color_t transparent = color_hex_to_pixman_with_alpha(0, 0);
pixman_image_fill_rectangles(
render: re-write cell clipping to use pixman destination clipping Our home rolled clip-to-cell code was, obviously, not correct. The original problem was that we couldn't use pixman clipping since we have multiple threads writing to the same pixman image, and thus there would be races between the threads setting clipping. The fix is actually simple - just instantiate one pixman image (referencing the same backing image data) for each rendering thread.
2020-06-04 15:39:19 +02:00
PIXMAN_OP_SRC, buf->pix[0], &transparent,
render: search: kwin has problems with a resizing/repositioned sub-surface So, make it equal to the window size, and make the non-used area fully transparent.
2020-03-01 12:28:33 +01:00
1, &(pixman_rectangle16_t){0, 0, width - visible_width, height});
search: move render() function to the 'render' module
2019-08-29 20:18:06 +02:00
fcft: adjust to fcft-2.0 API changes * font_*() -> fcft_*() * struct font -> struct fcft_font * struct glyph -> struct fcft_glyph * enum subpixel_order -> enum fcft_subpixel
2020-04-21 19:29:36 +02:00
struct fcft_font *font = term->fonts[0];
render: search: kwin has problems with a resizing/repositioned sub-surface So, make it equal to the window size, and make the non-used area fully transparent.
2020-03-01 12:28:33 +01:00
int x = width - visible_width + margin;
search: move render() function to the 'render' module
2019-08-29 20:18:06 +02:00
int y = margin;
render: search box: use colors from the color table Use the 'yellow' color from the 'regular' range of colors (SGR 33) for background when we have a match, or 'red' from the 'regular' range of colors (SGR 31) when we don't have a match. Foreground uses the 'black' color from the regular range of colors (SGR 30).
2019-08-30 21:01:13 +02:00
pixman_color_t fg = color_hex_to_pixman(term->colors.table[0]);
search: move render() function to the 'render' module
2019-08-29 20:18:06 +02:00
render: search: improve handling of very long search strings
2020-04-19 14:50:48 +02:00
/* Ensure cursor is visible */
if (term->search.cursor < glyph_offset)
search: rename render.search_offset -> render.search_glyph_offset
2020-01-05 15:25:24 +01:00
term->render.search_glyph_offset = glyph_offset = term->search.cursor;
render: search: improve handling of very long search strings
2020-04-19 14:50:48 +02:00
else if (term->search.cursor > glyph_offset + visible_chars) {
term->render.search_glyph_offset = glyph_offset =
term->search.cursor - min(term->search.cursor, visible_chars);
render: ensure cursor is always visible in the search box Maintain a view 'offset' (which glyph from the search string to start rendering at). This defines the start of the viewable area. The end is the offset + the search box size (which is limited to the window size). Adjust this offset whenever the cursor moves outside the viewable area. For now, this is always done in the same way: set the offset to the cursor position. This means that when we're entering text at the end of the search criteria (i.e. the normal case; we're simply typing), and the search box reaches the window size, the cursor will jump to the start of the search box, which will be empty. This could be confusing, but let's go with for now.
2020-01-05 15:16:40 +01:00
}
render: search: improve handling of very long search strings
2020-04-19 14:50:48 +02:00
/* Move offset if there is free space available */
if (term->search.len - glyph_offset < visible_chars)
term->render.search_glyph_offset = glyph_offset =
term->search.len - min(term->search.len, visible_chars);
search: move render() function to the 'render' module
2019-08-29 20:18:06 +02:00
/* Text (what the user entered - *not* match(es)) */
search: rename render.search_offset -> render.search_glyph_offset
2020-01-05 15:25:24 +01:00
for (size_t i = glyph_offset;
render: search: fix off-by-one error in number of visible characters
2020-02-29 11:41:40 +01:00
i < term->search.len && i - glyph_offset < visible_chars;
render: ensure cursor is always visible in the search box Maintain a view 'offset' (which glyph from the search string to start rendering at). This defines the start of the viewable area. The end is the offset + the search box size (which is limited to the window size). Adjust this offset whenever the cursor moves outside the viewable area. For now, this is always done in the same way: set the offset to the cursor position. This means that when we're entering text at the end of the search criteria (i.e. the normal case; we're simply typing), and the search box reaches the window size, the cursor will jump to the start of the search box, which will be empty. This could be confusing, but let's go with for now.
2020-01-05 15:16:40 +01:00
i++)
{
render: render_search_box: draw cursor as a bar
2019-08-29 21:03:00 +02:00
if (i == term->search.cursor)
render: re-write cell clipping to use pixman destination clipping Our home rolled clip-to-cell code was, obviously, not correct. The original problem was that we couldn't use pixman clipping since we have multiple threads writing to the same pixman image, and thus there would be races between the threads setting clipping. The fix is actually simple - just instantiate one pixman image (referencing the same backing image data) for each rendering thread.
2020-06-04 15:39:19 +02:00
draw_bar(term, buf->pix[0], font, &fg, x, y);
render: render_search_box: draw cursor as a bar
2019-08-29 21:03:00 +02:00
fcft: fcft_glyph_for_wc() has been renamed to fcft_glyph_rasterize()
2020-04-24 10:53:34 +02:00
const struct fcft_glyph *glyph = fcft_glyph_rasterize(
font, term->search.buf[i], true);
search: move render() function to the 'render' module
2019-08-29 20:18:06 +02:00
if (glyph == NULL)
continue;
pixman_image_t *src = pixman_image_create_solid_fill(&fg);
pixman_image_composite32(
render: re-write cell clipping to use pixman destination clipping Our home rolled clip-to-cell code was, obviously, not correct. The original problem was that we couldn't use pixman clipping since we have multiple threads writing to the same pixman image, and thus there would be races between the threads setting clipping. The fix is actually simple - just instantiate one pixman image (referencing the same backing image data) for each rendering thread.
2020-06-04 15:39:19 +02:00
PIXMAN_OP_OVER, src, glyph->pix, buf->pix[0], 0, 0, 0, 0,
render: font_baseline(): simply use the primary font's ascent This is what we used as baseline for regular glyphs anyway. Thus, we can update that code to call font_baseline() now. This makes it easier to change how we define the baseline in the future.
2019-11-30 14:51:44 +01:00
x + glyph->x, y + font_baseline(term) - glyph->y,
search: move render() function to the 'render' module
2019-08-29 20:18:06 +02:00
glyph->width, glyph->height);
pixman_image_unref(src);
render: search box: fix glyph spacing We're using the same font as in the terminal, so use the same glyph spacing.
2019-08-30 19:35:47 +02:00
x += term->cell_width;
search: move render() function to the 'render' module
2019-08-29 20:18:06 +02:00
}
render: render_search_box: draw cursor as a bar
2019-08-29 21:03:00 +02:00
if (term->search.cursor >= term->search.len)
render: re-write cell clipping to use pixman destination clipping Our home rolled clip-to-cell code was, obviously, not correct. The original problem was that we couldn't use pixman clipping since we have multiple threads writing to the same pixman image, and thus there would be races between the threads setting clipping. The fix is actually simple - just instantiate one pixman image (referencing the same backing image data) for each rendering thread.
2020-06-04 15:39:19 +02:00
draw_bar(term, buf->pix[0], font, &fg, x, y);
render: render_search_box: draw cursor as a bar
2019-08-29 21:03:00 +02:00
search: enable/disable weston sub-surface desync quirk when rendering search box
2020-03-01 13:06:00 +01:00
quirk_weston_subsurface_desync_on(term->window->search_sub_surface);
render: search: add todo to only position sub-surface on a window resize
2020-03-01 12:54:50 +01:00
/* TODO: this is only necessary on a window resize */
search: move render() function to the 'render' module
2019-08-29 20:18:06 +02:00
wl_subsurface_set_position(
wayland: implement wayl_init() Wayland instantiation is now done by the wayland backend, not in main.
2019-10-27 19:08:48 +01:00
term->window->search_sub_surface,
render: search: kwin has problems with a resizing/repositioned sub-surface So, make it equal to the window size, and make the non-used area fully transparent.
2020-03-01 12:28:33 +01:00
margin / scale,
render: wl_subsurface_set_position() uses un-scaled coordinates This fixes an issue where the CSDs and the search box was incorrectly positioned when output's scale != 1.
2020-02-29 11:40:41 +01:00
max(0, (int32_t)term->height - height - margin) / scale);
search: move render() function to the 'render' module
2019-08-29 20:18:06 +02:00
render: search: kwin has problems with a resizing/repositioned sub-surface So, make it equal to the window size, and make the non-used area fully transparent.
2020-03-01 12:28:33 +01:00
wl_surface_attach(term->window->search_surface, buf->wl_buf, 0, 0);
wl_surface_damage_buffer(term->window->search_surface, 0, 0, width, height);
wl_surface_set_buffer_scale(term->window->search_surface, scale);
render: search: mark visible portion of sub-surface opaque
2020-03-01 12:54:27 +01:00
struct wl_region *region = wl_compositor_create_region(term->wl->compositor);
if (region != NULL) {
wl_region_add(region, width - visible_width, 0, visible_width, height);
wl_surface_set_opaque_region(term->window->search_surface, region);
wl_region_destroy(region);
}
wayland: implement wayl_init() Wayland instantiation is now done by the wayland backend, not in main.
2019-10-27 19:08:48 +01:00
wl_surface_commit(term->window->search_surface);
search: enable/disable weston sub-surface desync quirk when rendering search box
2020-03-01 13:06:00 +01:00
quirk_weston_subsurface_desync_off(term->window->search_sub_surface);
search: move render() function to the 'render' module
2019-08-29 20:18:06 +02:00
}
render: pace title updates Synchronize window title updates with window rendering.
2020-03-25 18:23:55 +01:00
static void
render_update_title(struct terminal *term)
{
/* TODO: figure out what the limit actually is */
static const size_t max_len = 100;
const char *title = term->window_title != NULL ? term->window_title : "foot";
char *copy = NULL;
if (strlen(title) > max_len) {
copy = strndup(title, max_len);
title = copy;
}
xdg_toplevel_set_title(term->window->xdg_toplevel, title);
free(copy);
}
render: never render CSD and/or search box "immediately" Handle the CSDs and the search box the same way we handle the main grid; when we need to redraw them, call render_refresh_{csd,search}(). This sets a flag that is checked after each FDM iteration. All actual rendering is done here. This also ties the commits of the Wayland sub-surfaces to the commit of the main surface.
2020-03-06 19:16:54 +01:00
static void
frame_callback(void *data, struct wl_callback *wl_callback, uint32_t callback_data)
{
struct terminal *term = data;
assert(term->window->frame_callback == wl_callback);
wl_callback_destroy(wl_callback);
term->window->frame_callback = NULL;
render: fdm refresh handler: don't clear pending flags The pending flags may already be set (from a previous call to the FDM hook). In this case, they should not be cleared.
2020-03-24 17:42:29 +01:00
bool grid = term->render.pending.grid;
bool csd = term->render.pending.csd;
bool search = term->render.pending.search;
render: pace title updates Synchronize window title updates with window rendering.
2020-03-25 18:23:55 +01:00
bool title = term->render.pending.title;
render: fdm refresh handler: don't clear pending flags The pending flags may already be set (from a previous call to the FDM hook). In this case, they should not be cleared.
2020-03-24 17:42:29 +01:00
term->render.pending.grid = false;
term->render.pending.csd = false;
term->render.pending.search = false;
render: pace title updates Synchronize window title updates with window rendering.
2020-03-25 18:23:55 +01:00
term->render.pending.title = false;
render: fdm refresh handler: don't clear pending flags The pending flags may already be set (from a previous call to the FDM hook). In this case, they should not be cleared.
2020-03-24 17:42:29 +01:00
if (csd && term->window->use_csd == CSD_YES) {
quirk_weston_csd_on(term);
render_csd(term);
quirk_weston_csd_off(term);
render: never render CSD and/or search box "immediately" Handle the CSDs and the search box the same way we handle the main grid; when we need to redraw them, call render_refresh_{csd,search}(). This sets a flag that is checked after each FDM iteration. All actual rendering is done here. This also ties the commits of the Wayland sub-surfaces to the commit of the main surface.
2020-03-06 19:16:54 +01:00
}
render: pace title updates Synchronize window title updates with window rendering.
2020-03-25 18:23:55 +01:00
if (title)
render_update_title(term);
render: fdm refresh handler: don't clear pending flags The pending flags may already be set (from a previous call to the FDM hook). In this case, they should not be cleared.
2020-03-24 17:42:29 +01:00
if (search && term->is_searching)
render_search_box(term);
delayed rendering: ignore frame callback if delayed rendering is active Before, we applied delayed rendering (that is, we gave the client a chance to do more writes before we scheduled a render refresh) only when the renderer were idle. However, with e.g. a high keyboard repeat rate, it is very much possible to start the render loop and then never break out of it while receiving keyboard input. This causes screen flickering, as we're no longer even trying to detect the clients transaction boundaries. So, let's rewrite how this is done. First, we give the user the ability to disable delayed rendering altogether, by setting either the lower or upper timeout to 0. Second, when delayed rendering is enabled, we ignore the frame callback. That is, when receiving input, we *always* reschedule the lower timeout timer, regardless of whether the render is idle or not. The render's frame callback handler will *not* render the grid if the delayed render timers are armed. This means for longer client data bursts, we may now skip frames. That is, we're trading screen flicker for the occasional frame hickup. For short client data bursts we should behave roughly as before. This greatly improves the behavior of fullscreen, or near fullscreen, updates of large grids (example, scrolling in emacs in fullscreen, with a vertical buffer split).
2020-03-23 19:21:41 +01:00
render: fdm refresh handler: don't clear pending flags The pending flags may already be set (from a previous call to the FDM hook). In this case, they should not be cleared.
2020-03-24 17:42:29 +01:00
if (grid && (!term->delayed_render_timer.is_armed || csd || search))
grid_render(term);
render: never render CSD and/or search box "immediately" Handle the CSDs and the search box the same way we handle the main grid; when we need to redraw them, call render_refresh_{csd,search}(). This sets a flag that is checked after each FDM iteration. All actual rendering is done here. This also ties the commits of the Wayland sub-surfaces to the commit of the main surface.
2020-03-06 19:16:54 +01:00
}
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
/* Move to terminal.c? */
render: render_resize_*() returns a boolean indicating whether size changed.
2020-02-25 19:51:03 +01:00
static bool
render: add render_resize_force() This forces a full resize operation, even though actual window size (or scale) hasn't changed.
2020-02-08 14:08:16 +01:00
maybe_resize(struct terminal *term, int width, int height, bool force)
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
{
render: don't try to resize if we're shutting down This fixes an issue where we sometimes (depends on compositor?) tried to signal a TIOCSWINSZ and failed. This caused us to log a misleading error message.
2020-03-17 13:27:26 +01:00
if (term->is_shutting_down)
return false;
render: resize: ignore unconfigured windows
2020-02-26 12:21:03 +01:00
if (!term->window->is_configured)
return false;
render: resize with with/height == 0 resizes to user configured dimensions
2020-02-25 20:29:44 +01:00
if (term->cell_width == 0 && term->cell_height == 0)
render: render_resize_*() returns a boolean indicating whether size changed.
2020-02-25 19:51:03 +01:00
return false;
render: render_resize(): don't do anything if width or height is 0
2020-01-03 12:54:03 +01:00
output: track output we're mapped on, and use maximum scale Our surface may be on multiple outputs at the same time. In this case, we use the largest scale factor, and let the compositor down scale on the "other" output(s).
2019-08-12 21:49:17 +02:00
int scale = -1;
wayland: implement wayl_init() Wayland instantiation is now done by the wayland backend, not in main.
2019-10-27 19:08:48 +01:00
tll_foreach(term->window->on_outputs, it) {
output: track output we're mapped on, and use maximum scale Our surface may be on multiple outputs at the same time. In this case, we use the largest scale factor, and let the compositor down scale on the "other" output(s).
2019-08-12 21:49:17 +02:00
if (it->item->scale > scale)
scale = it->item->scale;
}
if (scale == -1) {
/* Haven't 'entered' an output yet? */
scale = 1;
}
render: multiply width/height with *new* scale factor, not old
2019-08-21 17:56:41 +02:00
width *= scale;
height *= scale;
output: initial support for output scaling * Not updated run-time; only scale at start up used * Multiple monitors (outputs) not supported, as we can't track which output we're on (yet).
2019-08-12 21:22:38 +02:00
render: remember, and use, last unmaximized size When the compositor wants us to decide the size (it sends a configure event with width/height == 0), then use the last unmaximized size, if there is one. If there isn't one, use the size from the user configuration.
2020-02-26 20:59:11 +01:00
if (width == 0 && height == 0) {
/*
* The compositor is letting us choose the size
*
* If we have a "last" used size - use that. Otherwise, use
* the size from the user configuration.
*/
if (term->unmaximized_width != 0 && term->unmaximized_height != 0) {
width = term->unmaximized_width;
height = term->unmaximized_height;
} else {
render: resize: exclude CSD borders when loading default geometry in maximized mode
2020-02-28 18:50:15 +01:00
width = term->conf->width;
height = term->conf->height;
if (term->window->use_csd == CSD_YES) {
wayland: set window geometry to exclude the invisible CSD borders But it *does* include the title bar. This simplifies the 'adjustment' needed to be done to the configured window size. It also fixes a number of issues: * the compositor will now properly snap the window to screen edges (before, there was an empty space between the edge and the window - the CSD border). * This also removes the need for the mutter 'commit' workaround. We must be doing something right now.
2020-03-03 18:26:15 +01:00
/* Take CSD title bar into account */
render: resize: exclude CSD borders when loading default geometry in maximized mode
2020-02-28 18:50:15 +01:00
assert(!term->window->is_fullscreen);
wayland: set window geometry to exclude the invisible CSD borders But it *does* include the title bar. This simplifies the 'adjustment' needed to be done to the configured window size. It also fixes a number of issues: * the compositor will now properly snap the window to screen edges (before, there was an empty space between the edge and the window - the CSD border). * This also removes the need for the mutter 'commit' workaround. We must be doing something right now.
2020-03-03 18:26:15 +01:00
height -= term->conf->csd.title_height;
render: resize: exclude CSD borders when loading default geometry in maximized mode
2020-02-28 18:50:15 +01:00
}
render: remember, and use, last unmaximized size When the compositor wants us to decide the size (it sends a configure event with width/height == 0), then use the last unmaximized size, if there is one. If there isn't one, use the size from the user configuration.
2020-02-26 20:59:11 +01:00
render: resize: exclude CSD borders when loading default geometry in maximized mode
2020-02-28 18:50:15 +01:00
width *= scale;
height *= scale;
render: remember, and use, last unmaximized size When the compositor wants us to decide the size (it sends a configure event with width/height == 0), then use the last unmaximized size, if there is one. If there isn't one, use the size from the user configuration.
2020-02-26 20:59:11 +01:00
}
}
render: render_resize(): don't allow too small window sizes
2020-02-25 19:10:48 +01:00
/* Don't shrink grid too much */
const int min_cols = 20;
const int min_rows = 4;
/* Minimum window size */
config: make CSD user configurable The user can now configure the following: * Whether to prefer CSDs or SSDs. But note that this is only a hint to the compositor - it may deny our request. Furthermore, not all compositors implement the decoration manager protocol, meaning CSDs will be used regardless of the user configuration (GNOME/mutter being the most prominent one). * Title bar size and color, including transparency * Border size and color, including transparency Also drop support for rendering the CSDs inside the main surface.
2020-03-02 18:42:49 +01:00
const int min_width = min_cols * term->cell_width;
const int min_height = min_rows * term->cell_height;
render: render_resize(): don't allow too small window sizes
2020-02-25 19:10:48 +01:00
width = max(width, min_width);
height = max(height, min_height);
config: make CSD user configurable The user can now configure the following: * Whether to prefer CSDs or SSDs. But note that this is only a hint to the compositor - it may deny our request. Furthermore, not all compositors implement the decoration manager protocol, meaning CSDs will be used regardless of the user configuration (GNOME/mutter being the most prominent one). * Title bar size and color, including transparency * Border size and color, including transparency Also drop support for rendering the CSDs inside the main surface.
2020-03-02 18:42:49 +01:00
/* Padding */
const int max_pad_x = (width - min_width) / 2;
const int max_pad_y = (height - min_height) / 2;
const int pad_x = min(max_pad_x, scale * term->conf->pad_x);
const int pad_y = min(max_pad_y, scale * term->conf->pad_y);
render: add render_resize_force() This forces a full resize operation, even though actual window size (or scale) hasn't changed.
2020-02-08 14:08:16 +01:00
if (!force && width == term->width && height == term->height && scale == term->scale)
render: render_resize_*() returns a boolean indicating whether size changed.
2020-02-25 19:51:03 +01:00
return false;
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
render: add render_{enable,disable}_refresh() Calling render_disable_refresh() causes update requests to that terminal to be ignored. Calling render_enable_refresh() re-enables updates.
2020-01-12 12:19:38 +01:00
/* Cancel an application initiated "Synchronized Update" */
term: shorten application_synchronized_updates -> app_sync_updates
2020-01-12 12:55:19 +01:00
term_disable_app_sync_updates(term);
render: add render_{enable,disable}_refresh() Calling render_disable_refresh() causes update requests to that terminal to be ignored. Calling render_enable_refresh() re-enables updates.
2020-01-12 12:19:38 +01:00
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
term->width = width;
term->height = height;
output: resize on scale changes
2019-08-12 21:32:38 +02:00
term->scale = scale;
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
render: special case worker-count == 0 Allow render worker count to be 0, in which case the main thread renders the entire screen.
2019-08-01 20:09:39 +02:00
const int scrollback_lines = term->render.scrollback_lines;
wip: initial scroll back support Can scroll up and down, and stops when the beginning/end of history is reached. However, it probably breaks when the entire scrollback buffer has been filled - we need to detect when the view has wrapped around to the current terminal offset. The detection of when we've reached the bottom of the history is also flawed, and only works when we overshoot the bottom with at least a page. Resizing the windows while in a view most likely doesn't work. The view will not detect a wrapped around scrollback buffer. I.e. if the user has scrolled back, and is stationary at a view, but there is still output being produced. Then eventually the scrollback buffer will wrap around. In this case, the correct thing to do is make the view start following the beginning of the history. Right now it doesn't, meaning once the scrollback buffer wraps around, you'll start seeing command output...
2019-07-09 16:26:36 +02:00
render: resize: take padding from configuration into account
2020-02-15 19:01:26 +01:00
/* Screen rows/cols before resize */
render: copy old contents to new grids when resizing Eventually, we'll add text reflow here as well.
2019-07-09 09:12:41 +02:00
const int old_cols = term->cols;
wip: grid is now represented as a grid, not a linear array The grid is now represented with an array of row *pointers*. Each row contains an array of cells (the row's columns). The main point of having row pointers is we can now move rows around almost for free. This is useful when scrolling with scroll margins for example, where we previously had to copy the lines in the margins. Now it's just a matter of swapping two pointers.
2019-07-08 13:57:31 +02:00
const int old_rows = term->rows;
render: resize: take padding from configuration into account
2020-02-15 19:01:26 +01:00
/* Screen rows/cols after resize */
config: make CSD user configurable The user can now configure the following: * Whether to prefer CSDs or SSDs. But note that this is only a hint to the compositor - it may deny our request. Furthermore, not all compositors implement the decoration manager protocol, meaning CSDs will be used regardless of the user configuration (GNOME/mutter being the most prominent one). * Title bar size and color, including transparency * Border size and color, including transparency Also drop support for rendering the CSDs inside the main surface.
2020-03-02 18:42:49 +01:00
const int new_cols = (term->width - 2 * pad_x) / term->cell_width;
const int new_rows = (term->height - 2 * pad_y) / term->cell_height;
render: resize: take padding from configuration into account
2020-02-15 19:01:26 +01:00
/* Grid rows/cols after resize */
scrolling: optimize row access by assuming number of rows is a power of 2 With this assumption, we can replace 'a % b' with 'a & (b - 1)'. In terms of instructions, this means a fast 'and' instead of a slow 'div'. Further optimize scrolling by: * not double-initializing empty rows. Previously, grid_row_alloc() called calloc(), which was then followed by a memset() when scrolling. This is of course unnecessary. * Don't loop the entire set of visible rows (this was done to ensure all visible rows had been allocated, and to prefetch the cell contents). This isn't necessary; only newly pulled in rows can be NULL. For now, don't prefetch at all.
2019-08-22 17:33:23 +02:00
const int new_normal_grid_rows = 1 << (32 - __builtin_clz(new_rows + scrollback_lines - 1));
const int new_alt_grid_rows = 1 << (32 - __builtin_clz(new_rows));
render: copy old contents to new grids when resizing Eventually, we'll add text reflow here as well.
2019-07-09 09:12:41 +02:00
render: resize: take padding from configuration into account
2020-02-15 19:01:26 +01:00
assert(new_cols >= 1);
assert(new_rows >= 1);
/* Margins */
config: make CSD user configurable The user can now configure the following: * Whether to prefer CSDs or SSDs. But note that this is only a hint to the compositor - it may deny our request. Furthermore, not all compositors implement the decoration manager protocol, meaning CSDs will be used regardless of the user configuration (GNOME/mutter being the most prominent one). * Title bar size and color, including transparency * Border size and color, including transparency Also drop support for rendering the CSDs inside the main surface.
2020-03-02 18:42:49 +01:00
term->margins.left = pad_x;
term->margins.top = pad_y;
term: resize: pre-calculate right/bottom margins
2020-02-24 18:38:11 +01:00
term->margins.right = term->width - new_cols * term->cell_width - term->margins.left;
term->margins.bottom = term->height - new_rows * term->cell_height - term->margins.top;
render: center grid in window Instead of placing the upper left corner of the grid at 0,0 in the window, center it.
2019-08-27 15:25:35 +02:00
config: make CSD user configurable The user can now configure the following: * Whether to prefer CSDs or SSDs. But note that this is only a hint to the compositor - it may deny our request. Furthermore, not all compositors implement the decoration manager protocol, meaning CSDs will be used regardless of the user configuration (GNOME/mutter being the most prominent one). * Title bar size and color, including transparency * Border size and color, including transparency Also drop support for rendering the CSDs inside the main surface.
2020-03-02 18:42:49 +01:00
assert(term->margins.left >= pad_x);
assert(term->margins.right >= pad_x);
assert(term->margins.top >= pad_y);
assert(term->margins.bottom >= pad_y);
render: render_resize(): don't allow too small window sizes
2020-02-25 19:10:48 +01:00
render/grid: move grid reflow code to grid.c
2020-02-15 22:19:08 +01:00
if (new_cols == old_cols && new_rows == old_rows) {
LOG_DBG("grid layout unaffected; skipping reflow");
goto damage_view;
render: initial support for text reflow The algorithm is as follows: Start at the beginning of the scrollback. That is, at the oldest emitted lines. This is done by taking the current offset, and adding the number of (old) screen rows, and then iterating until we find the first allocated line. Next, we iterate the entire old grid. At the beginning, we allocate a line for the new grid, and setup a global pointer for that line, and the current cell index. For each line in the old grid, iterate its cells. Copy the the cells over to the new line. Whenever the new line reaches its maximum number of columns, we line break it by increasing the current row index and allocating a new row (if necessary - we may be overwriting old scrollback if the new grid is smaller than the old grid). Whenever we reach the end of a line of the old grid, we insert a line break in the new grid's line too **if** the last cell in the old line was empty. If it was **not** empty, we **don't** line break the new line. Furthermore, empty cells in general need special consideration. A line ending with a string of empty cells doesn't have to be copied the new line. And more importantly, should **not** increase the new line's cell index (which may cause line breaks, which is incorrect). However, if a string of empty cells is followed by non empty cells, we need to copy all the preceding empty cells to the line too. When the entire scrollback history has been reflowed, we need to figure out the new grid's offset. This is done by trying to put the **last** emitted line at the bottom of the screen. I.e. the new offset is typically "last_line_idx - term->rows". However, we need to handle empty lines. So, after subtracting the number of screen rows, we _increase_ the offset until we see a non-empty line. This ensures we handle grid's that doesn't fill an entire screen. Finally, we need to re-position the cursor. This is done by trying to place the cursor **at** (_not_ after) the last emitted line. We keep the current cursor column as is (but possibly truncated, if the grid's width decreased).
2020-02-10 20:35:24 +01:00
}
render: copy old contents to new grids when resizing Eventually, we'll add text reflow here as well.
2019-07-09 09:12:41 +02:00
render: resize: need to translate selection coordinates While it *looked* like the selection was working before, it really wasn't. When rendering, we're looking at the cells' attributes to determine whether they have been selected or not. When copying text however, we use the terminal's 'selection' state, which consists of 'start' and 'end' coordinates. These need to be translated when reflowing text.
2020-04-17 22:18:02 +02:00
struct coord *const tracking_points[] = {
&term->selection.start,
&term->selection.end,
};
render/grid: move grid reflow code to grid.c
2020-02-15 22:19:08 +01:00
/* Reflow grids */
render: resize: need to translate selection coordinates While it *looked* like the selection was working before, it really wasn't. When rendering, we're looking at the cells' attributes to determine whether they have been selected or not. When copying text however, we use the terminal's 'selection' state, which consists of 'start' and 'end' coordinates. These need to be translated when reflowing text.
2020-04-17 22:18:02 +02:00
grid_reflow(
&term->normal, new_normal_grid_rows, new_cols, old_rows, new_rows,
term->grid == &term->normal ? ALEN(tracking_points) : 0,
term->grid == &term->normal ? tracking_points : NULL);
grid_reflow(
&term->alt, new_alt_grid_rows, new_cols, old_rows, new_rows,
term->grid == &term->alt ? ALEN(tracking_points) : 0,
term->grid == &term->alt ? tracking_points : NULL);
wip: grid is now represented as a grid, not a linear array The grid is now represented with an array of row *pointers*. Each row contains an array of cells (the row's columns). The main point of having row pointers is we can now move rows around almost for free. This is useful when scrolling with scroll margins for example, where we previously had to copy the lines in the margins. Now it's just a matter of swapping two pointers.
2019-07-08 13:57:31 +02:00
render: configure default tab stops when resizing the terminal
2019-11-16 10:54:56 +01:00
/* Reset tab stops */
tll_free(term->tab_stops);
for (int c = 0; c < new_cols; c += 8)
tll_push_back(term->tab_stops, c);
wip: grid is now represented as a grid, not a linear array The grid is now represented with an array of row *pointers*. Each row contains an array of cells (the row's columns). The main point of having row pointers is we can now move rows around almost for free. This is useful when scrolling with scroll margins for example, where we previously had to copy the lines in the margins. Now it's just a matter of swapping two pointers.
2019-07-08 13:57:31 +02:00
term->cols = new_cols;
term->rows = new_rows;
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
render: resize: change 'resize' log from info to debug
2020-02-28 18:51:51 +01:00
LOG_DBG("resize: %dx%d, grid: cols=%d, rows=%d "
"(left-margin=%d, right-margin=%d, top-margin=%d, bottom-margin=%d)",
term->width, term->height, term->cols, term->rows,
term->margins.left, term->margins.right, term->margins.top, term->margins.bottom);
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
/* Signal TIOCSWINSZ */
render: resize: don't try to signal TIOCSWINSZ on a closed ptmx FD
2020-05-27 18:23:35 +02:00
if (term->ptmx >= 0 && ioctl(term->ptmx, TIOCSWINSZ,
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
&(struct winsize){
.ws_row = term->rows,
.ws_col = term->cols,
render: resize: TIOCSWINSZ: don't include padding in ws_{x,y}pixel
2020-01-12 14:42:49 +01:00
.ws_xpixel = term->cols * term->cell_width,
.ws_ypixel = term->rows * term->cell_height}) == -1)
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
{
LOG_ERRNO("TIOCSWINSZ");
}
render: copy old contents to new grids when resizing Eventually, we'll add text reflow here as well.
2019-07-09 09:12:41 +02:00
if (term->scroll_region.start >= term->rows)
term->scroll_region.start = 0;
if (term->scroll_region.end >= old_rows)
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
term->scroll_region.end = term->rows;
render: render combining characters This is basically just a loop that renders additional glyphs on top off the base glyph. Since we now need access to the row struct, for the combining characters, the function prototype for 'render_cell()' has changed. When rendering the combining characters we also need to deal with broken fonts; some fonts use positive offsets (as if the combining character was a regular character), while others use a negative offset (to be used as if you had already advanced the pen position). We handle both - a positive offset is rendered just like a regular glyph. When we see a negative offset we simply add the width of a cell first.
2020-05-01 11:56:13 +02:00
term->render.last_cursor.row = NULL;
render/grid: move grid reflow code to grid.c
2020-02-15 22:19:08 +01:00
damage_view:
render: don't update last 'un-maximized' size when in fullscreen
2020-02-29 17:25:08 +01:00
if (!term->window->is_maximized && !term->window->is_fullscreen) {
render: remember, and use, last unmaximized size When the compositor wants us to decide the size (it sends a configure event with width/height == 0), then use the last unmaximized size, if there is one. If there isn't one, use the size from the user configuration.
2020-02-26 20:59:11 +01:00
term->unmaximized_width = term->width;
term->unmaximized_height = term->height;
}
wayland: set window geometry to exclude the invisible CSD borders But it *does* include the title bar. This simplifies the 'adjustment' needed to be done to the configured window size. It also fixes a number of issues: * the compositor will now properly snap the window to screen edges (before, there was an empty space between the edge and the window - the CSD border). * This also removes the need for the mutter 'commit' workaround. We must be doing something right now.
2020-03-03 18:26:15 +01:00
#if 0
/* TODO: doesn't include CSD title bar */
render: render_resize_*() returns a boolean indicating whether size changed.
2020-02-25 19:51:03 +01:00
xdg_toplevel_set_min_size(
term->window->xdg_toplevel, min_width / scale, min_height / scale);
wayland: set window geometry to exclude the invisible CSD borders But it *does* include the title bar. This simplifies the 'adjustment' needed to be done to the configured window size. It also fixes a number of issues: * the compositor will now properly snap the window to screen edges (before, there was an empty space between the edge and the window - the CSD border). * This also removes the need for the mutter 'commit' workaround. We must be doing something right now.
2020-03-03 18:26:15 +01:00
#endif
{
bool title_shown = !term->window->is_fullscreen &&
term->window->use_csd == CSD_YES;
int title_height = title_shown ? term->conf->csd.title_height : 0;
xdg_surface_set_window_geometry(
term->window->xdg_surface,
0,
-title_height,
term->width / term->scale,
term->height / term->scale + title_height);
render: oops, add missing '}'
2020-03-03 18:29:46 +01:00
}
render: resize: redraw search box, if visible
2020-02-29 11:42:00 +01:00
render: resize: reset scroll damage We've resized, and reset the render's 'last-buf' pointer; any scroll damage we have is **not** valid anymore.
2020-02-08 18:22:14 +01:00
tll_free(term->normal.scroll_damage);
tll_free(term->alt.scroll_damage);
render: resize: redraw search box, if visible
2020-02-29 11:42:00 +01:00
render: add render_resize_force() This forces a full resize operation, even though actual window size (or scale) hasn't changed.
2020-02-08 14:08:16 +01:00
term->render.last_buf = NULL;
render: reset "last cursor" when resizing The cell pointer is likely invalid since we realloc the grids. Besides. we're redrawing the entire window anyway.
2019-07-26 18:51:47 +02:00
term_damage_view(term);
render: never render CSD and/or search box "immediately" Handle the CSDs and the search box the same way we handle the main grid; when we need to redraw them, call render_refresh_{csd,search}(). This sets a flag that is checked after each FDM iteration. All actual rendering is done here. This also ties the commits of the Wayland sub-surfaces to the commit of the main surface.
2020-03-06 19:16:54 +01:00
render_refresh_csd(term);
render_refresh_search(term);
render: remove 'refresh' from render_resize()
2020-01-03 13:56:10 +01:00
render_refresh(term);
render: resize: redraw search box, if visible
2020-02-29 11:42:00 +01:00
render: render_resize_*() returns a boolean indicating whether size changed.
2020-02-25 19:51:03 +01:00
return true;
render: add render_resize_force() This forces a full resize operation, even though actual window size (or scale) hasn't changed.
2020-02-08 14:08:16 +01:00
}
render: render_resize_*() returns a boolean indicating whether size changed.
2020-02-25 19:51:03 +01:00
bool
render: add render_resize_force() This forces a full resize operation, even though actual window size (or scale) hasn't changed.
2020-02-08 14:08:16 +01:00
render_resize(struct terminal *term, int width, int height)
{
return maybe_resize(term, width, height, false);
}
render: render_resize_*() returns a boolean indicating whether size changed.
2020-02-25 19:51:03 +01:00
bool
render: add render_resize_force() This forces a full resize operation, even though actual window size (or scale) hasn't changed.
2020-02-08 14:08:16 +01:00
render_resize_force(struct terminal *term, int width, int height)
{
return maybe_resize(term, width, height, true);
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
}
multi-seat: enable xcursor theme support again
2020-07-08 18:08:39 +02:00
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
static void xcursor_callback(
void *data, struct wl_callback *wl_callback, uint32_t callback_data);
static const struct wl_callback_listener xcursor_listener = {
.done = &xcursor_callback,
};
static void
multi-seat: improve handling of multiple (mouse) pointers * xcursor always set for all pointers * xcursor sometimes not updated when it should be * mouse grabbed state wasn't per seat, but global (i.e. "does at least one seat enable mouse grabbing") * selection enabled state wasn't per seat
2020-07-09 09:52:11 +02:00
render_xcursor_update(struct seat *seat)
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
{
/* If called from a frame callback, we may no longer have mouse focus */
multi-seat: improve handling of multiple (mouse) pointers * xcursor always set for all pointers * xcursor sometimes not updated when it should be * mouse grabbed state wasn't per seat, but global (i.e. "does at least one seat enable mouse grabbing") * selection enabled state wasn't per seat
2020-07-09 09:52:11 +02:00
if (!seat->mouse_focus)
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
return;
multi-seat: improve handling of multiple (mouse) pointers * xcursor always set for all pointers * xcursor sometimes not updated when it should be * mouse grabbed state wasn't per seat, but global (i.e. "does at least one seat enable mouse grabbing") * selection enabled state wasn't per seat
2020-07-09 09:52:11 +02:00
seat->pointer.cursor = wl_cursor_theme_get_cursor(
seat->pointer.theme, seat->pointer.xcursor);
multi-seat: enable xcursor theme support again
2020-07-08 18:08:39 +02:00
if (seat->pointer.cursor == NULL) {
wayland: read XCURSOR_{THEME,SIZE} in reload_xcursor theme
2020-07-10 12:06:55 +02:00
LOG_ERR("failed to load xcursor pointer '%s'", seat->pointer.xcursor);
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
return;
}
multi-seat: improve handling of multiple (mouse) pointers * xcursor always set for all pointers * xcursor sometimes not updated when it should be * mouse grabbed state wasn't per seat, but global (i.e. "does at least one seat enable mouse grabbing") * selection enabled state wasn't per seat
2020-07-09 09:52:11 +02:00
const int scale = seat->pointer.scale;
multi-seat: enable xcursor theme support again
2020-07-08 18:08:39 +02:00
struct wl_cursor_image *image = seat->pointer.cursor->images[0];
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
wl_surface_attach(
multi-seat: enable xcursor theme support again
2020-07-08 18:08:39 +02:00
seat->pointer.surface, wl_cursor_image_get_buffer(image), 0, 0);
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
wl_pointer_set_cursor(
multi-seat: enable xcursor theme support again
2020-07-08 18:08:39 +02:00
seat->wl_pointer, seat->pointer.serial,
seat->pointer.surface,
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
image->hotspot_x / scale, image->hotspot_y / scale);
wl_surface_damage_buffer(
multi-seat: enable xcursor theme support again
2020-07-08 18:08:39 +02:00
seat->pointer.surface, 0, 0, INT32_MAX, INT32_MAX);
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
multi-seat: enable xcursor theme support again
2020-07-08 18:08:39 +02:00
wl_surface_set_buffer_scale(seat->pointer.surface, scale);
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
multi-seat: enable xcursor theme support again
2020-07-08 18:08:39 +02:00
assert(seat->pointer.xcursor_callback == NULL);
seat->pointer.xcursor_callback = wl_surface_frame(seat->pointer.surface);
wl_callback_add_listener(seat->pointer.xcursor_callback, &xcursor_listener, seat);
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
multi-seat: enable xcursor theme support again
2020-07-08 18:08:39 +02:00
wl_surface_commit(seat->pointer.surface);
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
}
static void
xcursor_callback(void *data, struct wl_callback *wl_callback, uint32_t callback_data)
{
multi-seat: enable xcursor theme support again
2020-07-08 18:08:39 +02:00
struct seat *seat = data;
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
multi-seat: enable xcursor theme support again
2020-07-08 18:08:39 +02:00
assert(seat->pointer.xcursor_callback == wl_callback);
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
wl_callback_destroy(wl_callback);
multi-seat: enable xcursor theme support again
2020-07-08 18:08:39 +02:00
seat->pointer.xcursor_callback = NULL;
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
multi-seat: improve handling of multiple (mouse) pointers * xcursor always set for all pointers * xcursor sometimes not updated when it should be * mouse grabbed state wasn't per seat, but global (i.e. "does at least one seat enable mouse grabbing") * selection enabled state wasn't per seat
2020-07-09 09:52:11 +02:00
if (seat->pointer.xcursor_pending) {
render_xcursor_update(seat);
seat->pointer.xcursor_pending = false;
render: xcursor: remove render_xcursor_refresh()
2020-01-05 00:10:44 +01:00
}
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
}
static void
fdm_hook_refresh_pending_terminals(struct fdm *fdm, void *data)
{
struct renderer *renderer = data;
multi-seat: enable xcursor theme support again
2020-07-08 18:08:39 +02:00
struct wayland *wayl = renderer->wayl;
render: xcursor: remove render_xcursor_refresh()
2020-01-05 00:10:44 +01:00
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
tll_foreach(renderer->wayl->terms, it) {
struct terminal *term = it->item;
render: never render CSD and/or search box "immediately" Handle the CSDs and the search box the same way we handle the main grid; when we need to redraw them, call render_refresh_{csd,search}(). This sets a flag that is checked after each FDM iteration. All actual rendering is done here. This also ties the commits of the Wayland sub-surfaces to the commit of the main surface.
2020-03-06 19:16:54 +01:00
if (!term->render.refresh.grid &&
!term->render.refresh.csd &&
!term->render.refresh.search)
{
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
continue;
render: never render CSD and/or search box "immediately" Handle the CSDs and the search box the same way we handle the main grid; when we need to redraw them, call render_refresh_{csd,search}(). This sets a flag that is checked after each FDM iteration. All actual rendering is done here. This also ties the commits of the Wayland sub-surfaces to the commit of the main surface.
2020-03-06 19:16:54 +01:00
}
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
render: never render CSD and/or search box "immediately" Handle the CSDs and the search box the same way we handle the main grid; when we need to redraw them, call render_refresh_{csd,search}(). This sets a flag that is checked after each FDM iteration. All actual rendering is done here. This also ties the commits of the Wayland sub-surfaces to the commit of the main surface.
2020-03-06 19:16:54 +01:00
if (term->render.app_sync_updates.enabled &&
!term->render.refresh.csd &&
!term->render.refresh.search)
{
render: add render_{enable,disable}_refresh() Calling render_disable_refresh() causes update requests to that terminal to be ignored. Calling render_enable_refresh() re-enables updates.
2020-01-12 12:19:38 +01:00
continue;
render: never render CSD and/or search box "immediately" Handle the CSDs and the search box the same way we handle the main grid; when we need to redraw them, call render_refresh_{csd,search}(). This sets a flag that is checked after each FDM iteration. All actual rendering is done here. This also ties the commits of the Wayland sub-surfaces to the commit of the main surface.
2020-03-06 19:16:54 +01:00
}
if (term->render.refresh.csd || term->render.refresh.search) {
/* Force update of parent surface */
term->render.refresh.grid = true;
}
render: add render_{enable,disable}_refresh() Calling render_disable_refresh() causes update requests to that terminal to be ignored. Calling render_enable_refresh() re-enables updates.
2020-01-12 12:19:38 +01:00
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
assert(term->window->is_configured);
render: never render CSD and/or search box "immediately" Handle the CSDs and the search box the same way we handle the main grid; when we need to redraw them, call render_refresh_{csd,search}(). This sets a flag that is checked after each FDM iteration. All actual rendering is done here. This also ties the commits of the Wayland sub-surfaces to the commit of the main surface.
2020-03-06 19:16:54 +01:00
bool grid = term->render.refresh.grid;
bool csd = term->render.refresh.csd;
bool search = term->render.refresh.search;
render: pace title updates Synchronize window title updates with window rendering.
2020-03-25 18:23:55 +01:00
bool title = term->render.refresh.title;
render: never render CSD and/or search box "immediately" Handle the CSDs and the search box the same way we handle the main grid; when we need to redraw them, call render_refresh_{csd,search}(). This sets a flag that is checked after each FDM iteration. All actual rendering is done here. This also ties the commits of the Wayland sub-surfaces to the commit of the main surface.
2020-03-06 19:16:54 +01:00
term->render.refresh.grid = false;
term->render.refresh.csd = false;
term->render.refresh.search = false;
render: pace title updates Synchronize window title updates with window rendering.
2020-03-25 18:23:55 +01:00
term->render.refresh.title = false;
render: never render CSD and/or search box "immediately" Handle the CSDs and the search box the same way we handle the main grid; when we need to redraw them, call render_refresh_{csd,search}(). This sets a flag that is checked after each FDM iteration. All actual rendering is done here. This also ties the commits of the Wayland sub-surfaces to the commit of the main surface.
2020-03-06 19:16:54 +01:00
if (term->window->frame_callback == NULL) {
if (csd && term->window->use_csd == CSD_YES) {
quirk_weston_csd_on(term);
render_csd(term);
quirk_weston_csd_off(term);
}
render: pace title updates Synchronize window title updates with window rendering.
2020-03-25 18:23:55 +01:00
if (title)
render_update_title(term);
render: never render CSD and/or search box "immediately" Handle the CSDs and the search box the same way we handle the main grid; when we need to redraw them, call render_refresh_{csd,search}(). This sets a flag that is checked after each FDM iteration. All actual rendering is done here. This also ties the commits of the Wayland sub-surfaces to the commit of the main surface.
2020-03-06 19:16:54 +01:00
if (search)
render_search_box(term);
if (grid)
grid_render(term);
} else {
render: xcursor: remove render_xcursor_refresh()
2020-01-05 00:10:44 +01:00
/* Tells the frame callback to render again */
render: fdm refresh handler: don't clear pending flags The pending flags may already be set (from a previous call to the FDM hook). In this case, they should not be cleared.
2020-03-24 17:42:29 +01:00
term->render.pending.grid |= grid;
term->render.pending.csd |= csd;
term->render.pending.search |= search;
render: pace title updates Synchronize window title updates with window rendering.
2020-03-25 18:23:55 +01:00
term->render.pending.title |= title;
render: xcursor: remove render_xcursor_refresh()
2020-01-05 00:10:44 +01:00
}
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
}
multi-seat: enable xcursor theme support again
2020-07-08 18:08:39 +02:00
tll_foreach(wayl->seats, it) {
multi-seat: improve handling of multiple (mouse) pointers * xcursor always set for all pointers * xcursor sometimes not updated when it should be * mouse grabbed state wasn't per seat, but global (i.e. "does at least one seat enable mouse grabbing") * selection enabled state wasn't per seat
2020-07-09 09:52:11 +02:00
if (it->item.pointer.xcursor_pending) {
multi-seat: enable xcursor theme support again
2020-07-08 18:08:39 +02:00
if (it->item.pointer.xcursor_callback == NULL) {
multi-seat: improve handling of multiple (mouse) pointers * xcursor always set for all pointers * xcursor sometimes not updated when it should be * mouse grabbed state wasn't per seat, but global (i.e. "does at least one seat enable mouse grabbing") * selection enabled state wasn't per seat
2020-07-09 09:52:11 +02:00
render_xcursor_update(&it->item);
it->item.pointer.xcursor_pending = false;
multi-seat: enable xcursor theme support again
2020-07-08 18:08:39 +02:00
} else {
/* Frame callback will call render_xcursor_update() */
}
render: xcursor: remove render_xcursor_refresh()
2020-01-05 00:10:44 +01:00
}
}
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
}
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
void
render: pace title updates Synchronize window title updates with window rendering.
2020-03-25 18:23:55 +01:00
render_refresh_title(struct terminal *term)
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
{
render: pace title updates Synchronize window title updates with window rendering.
2020-03-25 18:23:55 +01:00
term->render.refresh.title = true;
render: load cursor theme from XCURSOR_THEME and XCURSOR_SIZE
2019-07-05 10:44:09 +02:00
}
render: add render_refresh()
2019-07-24 20:09:49 +02:00
void
render_refresh(struct terminal *term)
{
render: never render CSD and/or search box "immediately" Handle the CSDs and the search box the same way we handle the main grid; when we need to redraw them, call render_refresh_{csd,search}(). This sets a flag that is checked after each FDM iteration. All actual rendering is done here. This also ties the commits of the Wayland sub-surfaces to the commit of the main surface.
2020-03-06 19:16:54 +01:00
term->render.refresh.grid = true;
}
void
render_refresh_csd(struct terminal *term)
{
if (term->window->use_csd == CSD_YES)
term->render.refresh.csd = true;
}
void
render_refresh_search(struct terminal *term)
{
if (term->is_searching)
term->render.refresh.search = true;
render: add render_refresh()
2019-07-24 20:09:49 +02:00
}
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
bool
multi-seat: improve handling of multiple (mouse) pointers * xcursor always set for all pointers * xcursor sometimes not updated when it should be * mouse grabbed state wasn't per seat, but global (i.e. "does at least one seat enable mouse grabbing") * selection enabled state wasn't per seat
2020-07-09 09:52:11 +02:00
render_xcursor_set(struct seat *seat, struct terminal *term, const char *xcursor)
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
{
multi-seat: enable xcursor theme support again
2020-07-08 18:08:39 +02:00
if (seat->pointer.theme == NULL)
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
return false;
multi-seat: enable xcursor theme support again
2020-07-08 18:08:39 +02:00
if (seat->mouse_focus == NULL) {
seat->pointer.xcursor = NULL;
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
return true;
}
multi-seat: enable xcursor theme support again
2020-07-08 18:08:39 +02:00
if (seat->mouse_focus != term) {
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
/* This terminal doesn't have mouse focus */
return true;
}
multi-seat: improve handling of multiple (mouse) pointers * xcursor always set for all pointers * xcursor sometimes not updated when it should be * mouse grabbed state wasn't per seat, but global (i.e. "does at least one seat enable mouse grabbing") * selection enabled state wasn't per seat
2020-07-09 09:52:11 +02:00
if (seat->pointer.xcursor == xcursor)
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
return true;
/* FDM hook takes care of actual rendering */
multi-seat: improve handling of multiple (mouse) pointers * xcursor always set for all pointers * xcursor sometimes not updated when it should be * mouse grabbed state wasn't per seat, but global (i.e. "does at least one seat enable mouse grabbing") * selection enabled state wasn't per seat
2020-07-09 09:52:11 +02:00
seat->pointer.xcursor_pending = true;
seat->pointer.xcursor = xcursor;
wip: multi-seat support Compiles and runs, but mouse, clipboard and other things have been disabled.
2020-07-08 16:45:26 +02:00
return true;
render: throttle xcursor updates With a bad behaving client (e.g. 'less' with mouse support enabled), we can end up with a *lot* of xcursor updates (so much, that we flooded the wayland socket before we implemented a blocking wayl_flush()). Since there's little point in updating the cursor more than once per frame interval, use frame callbacks to throttle the updates. This works more or lesslike normal terminal refreshes: render_xcursor_set() stores the last terminal (window) that had (and updated) the cursor. The renderer's FDM hook checks if we have such a pending terminal set, and if so, tries to refresh the cursor. This is done by first checking if we're already waiting for a callback from a previous cursor update, and if so we do nothing; the callback will update the cursor for the next frame. If we're *not* already waiting for a callback, we update the cursor immediately.
2020-01-04 22:01:19 +01:00
}
Reference in a new issue Copy permalink