2013-02-28 18:55:02 +00:00
|
|
|
/*
|
2013-09-09 16:37:33 +00:00
|
|
|
* This file is part of mpv video player.
|
2013-02-28 18:55:02 +00:00
|
|
|
*
|
Relicense some non-MPlayer source files to LGPL 2.1 or later
This covers source files which were added in mplayer2 and mpv times
only, and where all code is covered by LGPL relicensing agreements.
There are probably more files to which this applies, but I'm being
conservative here.
A file named ao_sdl.c exists in MPlayer too, but the mpv one is a
complete rewrite, and was added some time after the original ao_sdl.c
was removed. The same applies to vo_sdl.c, for which the SDL2 API is
radically different in addition (MPlayer supports SDL 1.2 only).
common.c contains only code written by me. But common.h is a strange
case: although it originally was named mp_common.h and exists in MPlayer
too, by now it contains only definitions written by uau and me. The
exceptions are the CONTROL_ defines - thus not changing the license of
common.h yet.
codec_tags.c contained once large tables generated from MPlayer's
codecs.conf, but all of these tables were removed.
From demux_playlist.c I'm removing a code fragment from someone who was
not asked; this probably could be done later (see commit 15dccc37).
misc.c is a bit complicated to reason about (it was split off mplayer.c
and thus contains random functions out of this file), but actually all
functions have been added post-MPlayer. Except get_relative_time(),
which was written by uau, but looks similar to 3 different versions of
something similar in each of the Unix/win32/OSX timer source files. I'm
not sure what that means in regards to copyright, so I've just moved it
into another still-GPL source file for now.
screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but
they're all gone.
2016-01-19 17:36:06 +00:00
|
|
|
* mpv is free software; you can redistribute it and/or
|
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
2013-02-28 18:55:02 +00:00
|
|
|
*
|
2013-09-09 16:37:33 +00:00
|
|
|
* mpv is distributed in the hope that it will be useful,
|
2013-02-28 18:55:02 +00:00
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
Relicense some non-MPlayer source files to LGPL 2.1 or later
This covers source files which were added in mplayer2 and mpv times
only, and where all code is covered by LGPL relicensing agreements.
There are probably more files to which this applies, but I'm being
conservative here.
A file named ao_sdl.c exists in MPlayer too, but the mpv one is a
complete rewrite, and was added some time after the original ao_sdl.c
was removed. The same applies to vo_sdl.c, for which the SDL2 API is
radically different in addition (MPlayer supports SDL 1.2 only).
common.c contains only code written by me. But common.h is a strange
case: although it originally was named mp_common.h and exists in MPlayer
too, by now it contains only definitions written by uau and me. The
exceptions are the CONTROL_ defines - thus not changing the license of
common.h yet.
codec_tags.c contained once large tables generated from MPlayer's
codecs.conf, but all of these tables were removed.
From demux_playlist.c I'm removing a code fragment from someone who was
not asked; this probably could be done later (see commit 15dccc37).
misc.c is a bit complicated to reason about (it was split off mplayer.c
and thus contains random functions out of this file), but actually all
functions have been added post-MPlayer. Except get_relative_time(),
which was written by uau, but looks similar to 3 different versions of
something similar in each of the Unix/win32/OSX timer source files. I'm
not sure what that means in regards to copyright, so I've just moved it
into another still-GPL source file for now.
screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but
they're all gone.
2016-01-19 17:36:06 +00:00
|
|
|
* GNU Lesser General Public License for more details.
|
2013-02-28 18:55:02 +00:00
|
|
|
*
|
Relicense some non-MPlayer source files to LGPL 2.1 or later
This covers source files which were added in mplayer2 and mpv times
only, and where all code is covered by LGPL relicensing agreements.
There are probably more files to which this applies, but I'm being
conservative here.
A file named ao_sdl.c exists in MPlayer too, but the mpv one is a
complete rewrite, and was added some time after the original ao_sdl.c
was removed. The same applies to vo_sdl.c, for which the SDL2 API is
radically different in addition (MPlayer supports SDL 1.2 only).
common.c contains only code written by me. But common.h is a strange
case: although it originally was named mp_common.h and exists in MPlayer
too, by now it contains only definitions written by uau and me. The
exceptions are the CONTROL_ defines - thus not changing the license of
common.h yet.
codec_tags.c contained once large tables generated from MPlayer's
codecs.conf, but all of these tables were removed.
From demux_playlist.c I'm removing a code fragment from someone who was
not asked; this probably could be done later (see commit 15dccc37).
misc.c is a bit complicated to reason about (it was split off mplayer.c
and thus contains random functions out of this file), but actually all
functions have been added post-MPlayer. Except get_relative_time(),
which was written by uau, but looks similar to 3 different versions of
something similar in each of the Unix/win32/OSX timer source files. I'm
not sure what that means in regards to copyright, so I've just moved it
into another still-GPL source file for now.
screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but
they're all gone.
2016-01-19 17:36:06 +00:00
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
|
* License along with mpv. If not, see <http://www.gnu.org/licenses/>.
|
2013-02-28 18:55:02 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef MPLAYER_WAYLAND_COMMON_H
|
|
|
|
|
#define MPLAYER_WAYLAND_COMMON_H
|
|
|
|
|
|
|
|
|
|
#include <wayland-client.h>
|
2024-09-26 22:28:35 +00:00
|
|
|
|
2017-10-01 20:16:49 +00:00
|
|
|
#include "input/event.h"
|
2024-09-26 22:28:35 +00:00
|
|
|
#include "video/mp_image.h"
|
2021-06-26 21:12:03 +00:00
|
|
|
#include "vo.h"
|
2013-02-28 18:55:02 +00:00
|
|
|
|
2024-10-01 03:11:16 +00:00
|
|
|
struct compositor_format;
|
2024-02-27 00:18:32 +00:00
|
|
|
struct vo_wayland_seat;
|
2024-10-01 03:11:16 +00:00
|
|
|
struct vo_wayland_tranche;
|
2023-02-08 02:03:35 +00:00
|
|
|
|
2024-09-08 06:05:03 +00:00
|
|
|
struct drm_format {
|
|
|
|
|
uint32_t format;
|
|
|
|
|
uint64_t modifier;
|
|
|
|
|
};
|
|
|
|
|
|
2013-07-18 15:35:28 +00:00
|
|
|
struct vo_wayland_state {
|
2024-07-23 23:22:50 +00:00
|
|
|
struct m_config_cache *opts_cache;
|
2022-05-30 17:58:57 +00:00
|
|
|
struct mp_log *log;
|
2024-07-23 23:22:50 +00:00
|
|
|
struct mp_vo_opts *opts;
|
2022-05-30 17:58:57 +00:00
|
|
|
struct vo *vo;
|
|
|
|
|
struct wl_callback *frame_callback;
|
|
|
|
|
struct wl_compositor *compositor;
|
|
|
|
|
struct wl_subcompositor *subcompositor;
|
|
|
|
|
struct wl_display *display;
|
|
|
|
|
struct wl_registry *registry;
|
|
|
|
|
struct wl_shm *shm;
|
|
|
|
|
struct wl_surface *surface;
|
2023-06-04 03:08:36 +00:00
|
|
|
struct wl_surface *osd_surface;
|
|
|
|
|
struct wl_subsurface *osd_subsurface;
|
2022-05-30 17:58:57 +00:00
|
|
|
struct wl_surface *video_surface;
|
2023-02-17 10:13:30 +00:00
|
|
|
struct wl_surface *callback_surface;
|
2022-05-30 17:58:57 +00:00
|
|
|
struct wl_subsurface *video_subsurface;
|
2021-06-26 21:12:03 +00:00
|
|
|
|
|
|
|
|
/* Geometry */
|
2017-10-01 20:16:49 +00:00
|
|
|
struct mp_rect geometry;
|
2021-06-26 21:12:03 +00:00
|
|
|
struct mp_rect window_size;
|
|
|
|
|
struct wl_list output_list;
|
|
|
|
|
struct vo_wayland_output *current_output;
|
2022-05-31 13:36:15 +00:00
|
|
|
int bounded_height;
|
|
|
|
|
int bounded_width;
|
2020-02-12 18:26:24 +00:00
|
|
|
int reduced_height;
|
2021-06-26 21:12:03 +00:00
|
|
|
int reduced_width;
|
|
|
|
|
|
|
|
|
|
/* State */
|
|
|
|
|
bool activated;
|
|
|
|
|
bool focused;
|
2019-10-10 19:14:40 +00:00
|
|
|
bool frame_wait;
|
2024-02-25 03:35:50 +00:00
|
|
|
bool geometry_configured;
|
2021-06-27 14:55:33 +00:00
|
|
|
bool hidden;
|
2023-08-26 21:39:09 +00:00
|
|
|
bool initial_size_hint;
|
2023-07-17 18:59:51 +00:00
|
|
|
bool locked_size;
|
2024-04-09 16:34:15 +00:00
|
|
|
bool need_rescale;
|
2024-04-12 03:16:18 +00:00
|
|
|
bool reconfigured;
|
wayland: fix vertical resizing
Resizing in strictly the vertical direction has been broken forever on
wayland. It's because of how the keepaspect calculation always resized
with respect to the width. So if you moved the mouse strictly
vertically with no change left/right, the mpv window would never change
size since it just calculates with respect to the width that doesn't
change.
Fixing this is kind of weird and maybe someone should think of a better
algorithm for preserving aspect ratio (we just multiply by the gcd
basically), but whatever. You might naively try something like "resize
with respect to what direction changes the most" at first, but this
leads to very cludgy resizing since during a typical mouse dragging
motion, it will flip constantly from "resize w/ respect to the width"
and "resize w/ respect to the height". It "works" but it's really ugly
and not worth it.
The trick is to realize that we need to consider the resizing state as
one continuous motion, choose a direction initially, stick to it
throughout the entirety of the resize, and reset the relevant parameters
after we finish the resize. This ensures the direction never
unintuitively flips during a motion, but also allows for the strictly
vertical case to still work.
Might as well note it here in the commit, but mpv's resizing behavior
technically violates xdg-shell. For the resizing event, "[t]he window
geometry specified in the configure event is a maximum; the client
cannot resize beyond it." Well, we do obviously go beyond the maximum in
certain cases. For example consider resizing strictly horizontally. The
width value increases from the compositor but not the height. Since mpv
preserves aspect ratio by default, the height obviously must increase
which will go over the prescribed bounds by the compositor. This happens
before and after this commit, and I think everyone agrees is the desired
behavior. With this commit, now vertical resizing works which violates
xdg-shell in the same way. Before, it incidentally obeyed the protocol
since it did not resize at all, but let's presume users expect the
window to actually get bigger when they do a drag resize.
*: https://wayland.app/protocols/xdg-shell#xdg_toplevel:enum:state:entry:resizing
2024-09-06 15:38:14 +00:00
|
|
|
bool resizing;
|
2024-03-04 15:42:15 +00:00
|
|
|
bool scale_configured;
|
2020-08-18 17:55:01 +00:00
|
|
|
bool state_change;
|
2023-07-17 19:14:36 +00:00
|
|
|
bool tiled;
|
2020-08-18 17:55:01 +00:00
|
|
|
bool toplevel_configured;
|
2021-06-26 21:12:03 +00:00
|
|
|
int display_fd;
|
|
|
|
|
int mouse_x;
|
|
|
|
|
int mouse_y;
|
|
|
|
|
int pending_vo_events;
|
2024-07-05 20:53:05 +00:00
|
|
|
int pending_scaling; // base 120
|
|
|
|
|
int scaling; // base 120
|
|
|
|
|
double scaling_factor; // wl->scaling divided by 120
|
wayland: fix vertical resizing
Resizing in strictly the vertical direction has been broken forever on
wayland. It's because of how the keepaspect calculation always resized
with respect to the width. So if you moved the mouse strictly
vertically with no change left/right, the mpv window would never change
size since it just calculates with respect to the width that doesn't
change.
Fixing this is kind of weird and maybe someone should think of a better
algorithm for preserving aspect ratio (we just multiply by the gcd
basically), but whatever. You might naively try something like "resize
with respect to what direction changes the most" at first, but this
leads to very cludgy resizing since during a typical mouse dragging
motion, it will flip constantly from "resize w/ respect to the width"
and "resize w/ respect to the height". It "works" but it's really ugly
and not worth it.
The trick is to realize that we need to consider the resizing state as
one continuous motion, choose a direction initially, stick to it
throughout the entirety of the resize, and reset the relevant parameters
after we finish the resize. This ensures the direction never
unintuitively flips during a motion, but also allows for the strictly
vertical case to still work.
Might as well note it here in the commit, but mpv's resizing behavior
technically violates xdg-shell. For the resizing event, "[t]he window
geometry specified in the configure event is a maximum; the client
cannot resize beyond it." Well, we do obviously go beyond the maximum in
certain cases. For example consider resizing strictly horizontally. The
width value increases from the compositor but not the height. Since mpv
preserves aspect ratio by default, the height obviously must increase
which will go over the prescribed bounds by the compositor. This happens
before and after this commit, and I think everyone agrees is the desired
behavior. With this commit, now vertical resizing works which violates
xdg-shell in the same way. Before, it incidentally obeyed the protocol
since it did not resize at all, but let's presume users expect the
window to actually get bigger when they do a drag resize.
*: https://wayland.app/protocols/xdg-shell#xdg_toplevel:enum:state:entry:resizing
2024-09-06 15:38:14 +00:00
|
|
|
int resizing_constraint;
|
2021-06-26 21:12:03 +00:00
|
|
|
int timeout_count;
|
|
|
|
|
int wakeup_pipe[2];
|
|
|
|
|
|
2024-09-26 22:28:35 +00:00
|
|
|
/* color-management */
|
|
|
|
|
struct xx_color_manager_v4 *color_manager;
|
|
|
|
|
struct xx_color_management_surface_v4 *color_surface;
|
|
|
|
|
struct xx_image_description_v4 *image_description;
|
|
|
|
|
struct xx_image_description_creator_params_v4 *image_creator_params;
|
|
|
|
|
struct mp_image_params target_params;
|
|
|
|
|
bool supports_icc;
|
|
|
|
|
bool supports_parametric;
|
|
|
|
|
bool supports_primaries;
|
|
|
|
|
bool supports_tf_power;
|
|
|
|
|
bool supports_luminances;
|
|
|
|
|
bool supports_display_primaries;
|
|
|
|
|
bool unsupported_colorspace;
|
|
|
|
|
int primaries_map[PL_COLOR_PRIM_COUNT];
|
|
|
|
|
int transfer_map[PL_COLOR_TRC_COUNT];
|
|
|
|
|
|
wayland: add support for content-type protocol
The content-type protocol allows mpv to send compositor a hint about the
type of content being displayed on its surface so it could potentially
make some sort of optimization. Fundamentally, this is pretty simple but
since this requires a very new wayland-protocols version (1.27), we have
to mess with the build to add a new define and add a bunch of if's in
here. The protocol itself exposes 4 different types of content: none,
photo, video, and game.
To do that, let's add a new option (wayland-content-type) that lets
users control what hint to send to the compossitor. Since the previous
commit adds a VOCTRL that notifies us about the content being displayed,
we can also add an auto value to this option. As you'd expect, the
compositor hint would be set to photo if mpv's core detects an image,
video for other things, and it is set to none for the special case of
forcing a window when there is not a video track. For completion's sake,
game is also allowed as a value for this option, but in practice there
shouldn't be a reason to use that.
2022-11-15 21:51:45 +00:00
|
|
|
/* content-type */
|
2024-07-05 15:35:57 +00:00
|
|
|
struct wp_content_type_manager_v1 *content_type_manager;
|
|
|
|
|
struct wp_content_type_v1 *content_type;
|
wayland: add support for content-type protocol
The content-type protocol allows mpv to send compositor a hint about the
type of content being displayed on its surface so it could potentially
make some sort of optimization. Fundamentally, this is pretty simple but
since this requires a very new wayland-protocols version (1.27), we have
to mess with the build to add a new define and add a bunch of if's in
here. The protocol itself exposes 4 different types of content: none,
photo, video, and game.
To do that, let's add a new option (wayland-content-type) that lets
users control what hint to send to the compossitor. Since the previous
commit adds a VOCTRL that notifies us about the content being displayed,
we can also add an auto value to this option. As you'd expect, the
compositor hint would be set to photo if mpv's core detects an image,
video for other things, and it is set to none for the special case of
forcing a window when there is not a video track. For completion's sake,
game is also allowed as a value for this option, but in practice there
shouldn't be a reason to use that.
2022-11-15 21:51:45 +00:00
|
|
|
int current_content_type;
|
|
|
|
|
|
2023-05-19 22:07:25 +00:00
|
|
|
/* cursor-shape */
|
|
|
|
|
/* TODO: unvoid these if required wayland protocols is bumped to 1.32+ */
|
|
|
|
|
void *cursor_shape_manager;
|
|
|
|
|
|
2023-01-23 20:16:43 +00:00
|
|
|
/* fractional-scale */
|
2024-07-05 15:35:57 +00:00
|
|
|
struct wp_fractional_scale_manager_v1 *fractional_scale_manager;
|
|
|
|
|
struct wp_fractional_scale_v1 *fractional_scale;
|
2023-01-23 20:16:43 +00:00
|
|
|
|
2021-06-26 21:12:03 +00:00
|
|
|
/* idle-inhibit */
|
|
|
|
|
struct zwp_idle_inhibit_manager_v1 *idle_inhibit_manager;
|
|
|
|
|
struct zwp_idle_inhibitor_v1 *idle_inhibitor;
|
|
|
|
|
|
2022-05-30 17:58:57 +00:00
|
|
|
/* linux-dmabuf */
|
2024-10-01 03:11:16 +00:00
|
|
|
struct wl_list tranche_list;
|
|
|
|
|
struct vo_wayland_tranche *current_tranche;
|
2022-05-30 17:58:57 +00:00
|
|
|
struct zwp_linux_dmabuf_v1 *dmabuf;
|
2023-06-12 19:34:50 +00:00
|
|
|
struct zwp_linux_dmabuf_feedback_v1 *dmabuf_feedback;
|
2024-10-01 03:11:16 +00:00
|
|
|
struct compositor_format *compositor_format_map;
|
2024-09-07 23:45:15 +00:00
|
|
|
uint32_t compositor_format_size;
|
2021-06-26 21:12:03 +00:00
|
|
|
|
|
|
|
|
/* presentation-time */
|
2019-10-10 19:14:40 +00:00
|
|
|
struct wp_presentation *presentation;
|
2023-01-14 01:28:46 +00:00
|
|
|
struct vo_wayland_feedback_pool *fback_pool;
|
2022-06-10 16:49:28 +00:00
|
|
|
struct mp_present *present;
|
2021-04-16 19:55:15 +00:00
|
|
|
int64_t refresh_interval;
|
2024-06-27 03:30:36 +00:00
|
|
|
bool present_clock;
|
2022-10-04 16:05:00 +00:00
|
|
|
bool use_present;
|
2019-10-10 19:14:40 +00:00
|
|
|
|
2022-11-16 01:52:56 +00:00
|
|
|
/* single-pixel-buffer */
|
2024-07-05 15:35:57 +00:00
|
|
|
struct wp_single_pixel_buffer_manager_v1 *single_pixel_manager;
|
2022-11-16 01:52:56 +00:00
|
|
|
|
2022-05-30 17:58:57 +00:00
|
|
|
/* xdg-decoration */
|
|
|
|
|
struct zxdg_decoration_manager_v1 *xdg_decoration_manager;
|
|
|
|
|
struct zxdg_toplevel_decoration_v1 *xdg_toplevel_decoration;
|
|
|
|
|
int requested_decoration;
|
|
|
|
|
|
|
|
|
|
/* xdg-shell */
|
|
|
|
|
struct xdg_wm_base *wm_base;
|
|
|
|
|
struct xdg_surface *xdg_surface;
|
|
|
|
|
struct xdg_toplevel *xdg_toplevel;
|
|
|
|
|
|
|
|
|
|
/* viewporter */
|
|
|
|
|
struct wp_viewporter *viewporter;
|
|
|
|
|
struct wp_viewport *viewport;
|
2024-02-25 04:59:27 +00:00
|
|
|
struct wp_viewport *cursor_viewport;
|
2023-06-04 03:08:36 +00:00
|
|
|
struct wp_viewport *osd_viewport;
|
2022-05-30 17:58:57 +00:00
|
|
|
struct wp_viewport *video_viewport;
|
|
|
|
|
|
2017-10-01 20:16:49 +00:00
|
|
|
/* Input */
|
2024-02-12 04:42:37 +00:00
|
|
|
struct wl_list seat_list;
|
2017-10-01 20:16:49 +00:00
|
|
|
struct xkb_context *xkb_context;
|
|
|
|
|
|
|
|
|
|
/* DND */
|
2021-06-26 21:12:03 +00:00
|
|
|
struct wl_data_device_manager *dnd_devman;
|
2017-10-01 20:16:49 +00:00
|
|
|
struct wl_data_offer *dnd_offer;
|
2024-02-28 17:16:51 +00:00
|
|
|
int dnd_action; // actually enum mp_dnd_action
|
2017-10-01 20:16:49 +00:00
|
|
|
char *dnd_mime_type;
|
|
|
|
|
int dnd_fd;
|
2021-06-26 21:12:03 +00:00
|
|
|
int dnd_mime_score;
|
2017-10-01 20:16:49 +00:00
|
|
|
|
|
|
|
|
/* Cursor */
|
|
|
|
|
struct wl_cursor_theme *cursor_theme;
|
|
|
|
|
struct wl_cursor *default_cursor;
|
|
|
|
|
struct wl_surface *cursor_surface;
|
2019-02-04 10:27:49 +00:00
|
|
|
bool cursor_visible;
|
2021-06-26 21:12:03 +00:00
|
|
|
int allocated_cursor_scale;
|
2024-02-27 00:18:32 +00:00
|
|
|
struct vo_wayland_seat *last_button_seat;
|
2013-02-28 18:55:02 +00:00
|
|
|
};
|
|
|
|
|
|
2022-04-07 04:01:21 +00:00
|
|
|
bool vo_wayland_check_visible(struct vo *vo);
|
2024-10-01 03:11:16 +00:00
|
|
|
bool vo_wayland_valid_format(struct vo_wayland_state *wl, uint32_t drm_format, uint64_t modifier);
|
2023-01-08 19:16:47 +00:00
|
|
|
bool vo_wayland_init(struct vo *vo);
|
2023-01-08 20:02:13 +00:00
|
|
|
bool vo_wayland_reconfig(struct vo *vo);
|
2022-04-07 04:01:21 +00:00
|
|
|
|
2022-05-30 17:19:23 +00:00
|
|
|
int vo_wayland_allocate_memfd(struct vo *vo, size_t size);
|
2021-06-26 21:12:03 +00:00
|
|
|
int vo_wayland_control(struct vo *vo, int *events, int request, void *arg);
|
|
|
|
|
|
2024-09-26 22:28:35 +00:00
|
|
|
void vo_wayland_handle_color(struct vo_wayland_state *wl);
|
2024-01-20 18:41:11 +00:00
|
|
|
void vo_wayland_handle_scale(struct vo_wayland_state *wl);
|
2023-02-27 11:12:09 +00:00
|
|
|
void vo_wayland_set_opaque_region(struct vo_wayland_state *wl, bool alpha);
|
2021-06-26 21:12:03 +00:00
|
|
|
void vo_wayland_sync_swap(struct vo_wayland_state *wl);
|
2017-10-01 20:16:49 +00:00
|
|
|
void vo_wayland_uninit(struct vo *vo);
|
2023-09-18 02:34:32 +00:00
|
|
|
void vo_wayland_wait_events(struct vo *vo, int64_t until_time_ns);
|
wayland: shuffle around the render loop again
Take two. f4e89dd went wrong by moving vo_wayland_wait_frame before
start_frame was called. Whether or not this matters depends on the
compositor, but some weird things can happen. Basically, it's a
scheduling issue. vo_wayland_wait_frame queues all events and sends them
to the server to process (with no blocking if presentation time is
available). If mpv changes state while rendering (and this function is
called before every frame is drawn), then that event also gets
dispatched and sent to the compositor. This, in some cases, can cause
some funny behavior because the next frame gets attached to the surface
while the old buffer is getting released. It's safer to call this
function after the swap already happens and well before mpv calls its
next draw. There's no weird scheduling of events, and the compositor log
is more normal.
The second part of this is to fix some stuttering issues. This is mostly
just conjecture, but probably what was happening was this thing called
"composition". The easiest way to see this is to play a video on the
default audio sync mode (probably easiest to see on a typical 23.976
video). Have that in a window and float it over firefox (floating
windows are bloat on a tiling wm anyway). Then in firefox, do some short
bursts of smooth scrolling (likely uses egl). Some stutter in video
rendering could be observed, particularly in panning shots.
Compositors are supposed to prevent tearing so what likely was happening
was that the compositor was simply holding the buffer a wee bit longer
to make sure it happened in sync with the smooth scrolling. Because the
mpv code waits precisely on presentation time, the loop would timeout on
occasion instead of receiving the frame callback. This would then lead
to a skipped frame when rendering and thus causing stuttering.
The fix is simple: just only count consecutive timeouts as not receiving
frame callback. If a compositor holds the mpv buffer slightly longer to
avoid tearing, then we will definitely receive frame callback on the
next round of the render loop. This logic also appears to be sound for
plasma (funfact: Plasma always returns frame callback even when the
window is hidden. Not sure what's up with that, but luckily it doesn't
matter to us.), so get rid of the goofy 1/vblank_time thing and just
keep it a simple > 1 check.
2021-05-23 19:36:19 +00:00
|
|
|
void vo_wayland_wait_frame(struct vo_wayland_state *wl);
|
2021-06-26 21:12:03 +00:00
|
|
|
void vo_wayland_wakeup(struct vo *vo);
|
2013-02-28 18:55:02 +00:00
|
|
|
|
|
|
|
|
#endif /* MPLAYER_WAYLAND_COMMON_H */
|
