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

53 lines
1.4 KiB
C
Raw Permalink Normal View History

render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
#pragma once
render: render_resize_*() returns a boolean indicating whether size changed.
2020-02-25 19:51:03 +01:00
#include <stdbool.h>
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
#include "terminal.h"
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
#include "fdm.h"
#include "wayland.h"
replace gettimeofday with clock_gettime POSIX.1-2008 has marked gettimeofday(2) as obsolete, recommending the use of clock_gettime(2) instead. CLOCK_MONOTONIC has been used instead of CLOCK_REALTIME because it is unaffected by manual changes in the system clock. This makes it better for our purposes, namely, measuring the difference between two points in time. tv_sec has been casted to long in most places since POSIX does not define the actual type of time_t.
2022-01-15 14:56:13 +05:30
#include "misc.h"
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
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 renderer *render_init(struct fdm *fdm, struct wayland *wayl);
void render_destroy(struct renderer *renderer);
render: break out rendering functions to render.{c,h}
2019-07-05 10:16:56 +02:00
feature: add resize-by-cells option to constrain window sizes... ...to multiples of the cell size, and preserve grid size when changing fonts or display scales in floating windows.
2024-01-17 15:00:14 -05:00
enum resize_options {
RESIZE_NORMAL = 0,
RESIZE_FORCE = 1 << 0,
RESIZE_BY_CELLS = 1 << 1,
RESIZE_KEEP_GRID = 1 << 2,
};
bool render_resize(
struct terminal *term, int width, int height, uint8_t resize_options);
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: add render_refresh()
2019-07-24 20:09:49 +02:00
void render_refresh(struct terminal *term);
osc: add support for osc 176 (app ID) This adds support for a new OSC escape sequence: OSC 176, that lets terminal programs tell the terminal the name of the app that is running. foot then sets the app ID of the toplevel to that ID, which lets the compositor know which app is running, and typically sets the appropriate icon, window grouping, ... See: https://gist.github.com/delthas/d451e2cc1573bb2364839849c7117239
2023-09-04 14:02:05 +02:00
void render_refresh_app_id(struct terminal *term);
toplevel-icon: implement OSC-1, CSI 20/21/22/23 t * The toplevel icon is now set to the app-id, unless "overridden" by OSC-1 or OSC-0. * Implemented OSC-1 * OSC-0 extended to also set the icon * Implemented CSI 20 t - report window icon * Implemented CSI 21 t - report window title * Implemented CSI 22 ; 1 t - push window icon * Implemented CS 23 ; 1 t - pop window icon * Extended CSI 22/23 ; 0 t to also push/pop the icon * Verify app-id set by OSC-176 is valid UTF-8 * Verify icon set by OSC-0/1 is valid UTF-8
2024-09-10 18:53:38 +02:00
void render_refresh_icon(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
void render_refresh_csd(struct terminal *term);
void render_refresh_search(struct terminal *term);
render: pace title updates Synchronize window title updates with window rendering.
2020-03-25 18:23:55 +01:00
void render_refresh_title(struct terminal *term);
urls: initial support for detecting URLs and rendering jump-labels The jump labels work, but is currently hardcoded to use xdg-open
2021-01-31 11:12:07 +01:00
void render_refresh_urls(struct terminal *term);
render: add render_xcursor_is_valid() Returns true if the provided cursor name is non-NULL, and exist in the currently loaded xcursor theme.
2022-01-01 13:56:15 +01:00
bool render_xcursor_set(
refactor: track current xcursor using an enum, instead of a char pointer
2023-06-27 16:57:33 +02:00
struct seat *seat, struct terminal *term, enum cursor_shape shape);
render: add render_xcursor_is_valid() Returns true if the provided cursor name is non-NULL, and exist in the currently loaded xcursor theme.
2022-01-01 13:56:15 +01:00
bool render_xcursor_is_valid(const struct seat *seat, const char *cursor);
wip: initial multithreaded renderer
2019-07-29 20:13:26 +02:00
render: Expose render_overlay This function updates the overlay that foot uses. It will be used to update the overlay when the flash effect ends.
2025-01-04 22:26:00 -05:00
void render_overlay(struct terminal *term);
wip: initial multithreaded renderer
2019-07-29 20:13:26 +02:00
struct render_worker_context {
int my_id;
struct terminal *term;
};
int render_worker_thread(void *_ctx);
input: Add support for xdg_toplevl.show_window_menu() This makes, if the compositor supports it, the window menu appear when right clicking on the title bar.
2021-11-19 15:08:46 +01:00
struct csd_data {
int x;
int y;
int width;
int height;
};
struct csd_data get_csd_data(const struct terminal *term, enum csd_surface surf_idx);
render: when double-buffering, pre-apply previous frame's damage early Foot likes it when compositor releases buffer immediately, as that means we only have to re-render the cells that have changed since the last frame. For various reasons, not all compositors do this. In this case, foot is typically forced to switch between two buffers, i.e. double-buffer. In this case, each frame starts with copying over the damage from the previous frame, to the new frame. Then we start rendering the updated cells. Bringing over the previous frame's damage can be slow, if the changed area was large (e.g. when scrolling one or a few lines, or on full screen updates). It's also done single-threaded. Thus it not only slows down frame rendering, but pauses everything else (i.e. input processing). All in all, it reduces performance and increases input latency. But we don't have to wait until it's time to render a frame to copy over the previous frame's damage. We can do that as soon as the compositor has released the buffer (for the frame _before_ the previous frame). And we can do this in a thread. This frees up foot to continue processing input, and reduces frame rendering time since we can now start rendering the modified cells immediately, without first doing a large memcpy(3). In worst case scenarios (or perhaps we should consider them best case scenarios...), I've seen up to a 10x performance increase in frame rendering times (this obviously does *not* include the time it takes to copy over the previous frame's damage, since that doesn't affect neither input processing nor frame rendering). Implemented by adding a callback mechanism to the shm abstraction layer. Use it for the grid buffers, and kick off a thread that copies the previous frame's damage, and resets the buffers age to 0 (so that foot understands it can start render to it immediately when it later needs to render a frame). Since we have certain way of knowing if a compositor releases buffers immediately or not, use a bit of heuristics; if we see 10 consecutive non-immediate releases (that is, we reset the counter as soon as we do see an immediate release), this new "pre-apply damage" logic is enabled. It can be force-disabled with tweak.pre-apply-damage=no. We also need to take care to wait for the thread before resetting the render's "last_buf" pointer (or we'll SEGFAULT in the thread...). We must also ensure we wait for the thread to finish before we start rendering a new frame. Under normal circumstances, the wait time is always 0, the thread has almost always finished long before we need to render the next frame. But it _can_ happen. Closes #2188
2025-10-05 10:48:36 +02:00
void render_buffer_release_callback(struct buffer *buf, void *data);
wayland: wait for pre-apply damage thread before destroying a terminal instance It's possible, but unlikely, that we've pushed a "pre-apply damage" job to the renderer thread queue (or that we've pushed it, and the a thread is now working on it) when we shutdown a terminal instance. This is sometimes caught in an assertion in term_destroy(), where we check the queue length is 0. Other times, or in release builds, we might crash in the thread, or in the shutdown logic when freeing the buffer chains associated with the terminal instance. Fix by ensuring there's no pre-apply damage operation queued, or running, before shutting down a terminal instance. Closes #2263
2026-01-28 09:44:57 +01:00
void render_wait_for_preapply_damage(struct terminal *term);
Reference in a new issue Copy permalink