Implement VOCTRL_GET_DISPLAY_FPS and VOCTRL_GET_DISPLAY_RES by returning
values obtained from Vulkan.
Currently, display fps and resolution info is not available in the
displayvk context. Display fps is needed for display sync to work
properly. The information is also used as the value of a few properties.
This slightly improves parity with the drm context.
When this was originally implemented, I lazily skipped the optimization
when using display sync because mpv would rip through all the frames
without waiting since there was no blocking. With the previous commits,
we now fall back on the audio sync logic when the window is not visible,
so the extra condition can be removed.
The previous commit put all the pieces in place so now this can be
implemented. Scheduling frames is already written with the assumption
that display sync maybe turn on/off at any time. So all that needs to be
done is check if the VO reports that it is not visible. If so, simply
flip mpctx->display_sync_active to false for that frame and skip the
display sync frame handling. It will become true again when the mpv
window comes back into view.
x11 and wayland VOs + backends all have logic that skips drawing frames
when the mpv isn't visible for efficiency reasons. This is implemented
in each individual VO, but it is useful for the core to be aware of this
as well. Currently, the display-sync modes on x11 do not try to be
efficient and always render anyways because there is no blocking on the
graphics API level if you skip rendering a frame (wayland works here by
accident). This means mpv would otherwise blaze through frames which is
not what anyone wants. We can instead improve this by implementing the
blocking mechanism in the core and using that when appropriate. This
commit does not implement that yet, but simply switches the draw_frame
to a boolean. Receiving false means that the VO is not drawing frames
and it should be treated as if the surface was hidden.
the equivalent options have been deprecated since mpv 0.35 in ac39661
and 2207236.
also bumping the MPV_CLIENT_API_VERSION to 2.5, since 2.4 was forgotten
in 6f619d5.
There were a few pitfalls with the way this was previously implemented
because --geometry implicitly depended on --auto-window-resize being
enabled to operate in a few cases. Instead, let's change the logic a bit
so that instead we choose whether or not to reuse the old rc (i.e. don't
resize) and use the wh_valid and xy_valid fields within the m_geometry
struct instead of using x11->geometry_change. This fixes several edge
cases involving setting the position with --geometry when using
--auto-window-resize=no.
This is still used for caclulating a/v sync and delay remaining even
for initial samples, so we should always update it to the actual vsync
for those initial samples so we have something to work with at least.
And if we receive bogus values, also reset it to 0 along with
prev_vsync.
Not having base_vsync set to _some_ value completely breaks
vsync_skip_detection, and mpv stays stuck in a permanent mistimed state
where every frame is marked as delayed and never recovers from it.
This is already done in WndProc, but the flag was not set if we exited
event loop and were processing mpv dispatch messages in fallback loop.
This fixes the case when Window is destroyed externally or otherwise
event loop fails for whatever reason. Calling vo_w32_uninit does call
DestroyWindow() through dispatch, which in turn calls WndProc, so we
need to guard recursive call.
This ignores --video-align-{x,y} when the video is smaller than the
window in the respective direction.
After zooming in, panning and zooming out, this is useful to recenter
the video in the window.
Unlike doing this by observing osd-dimensions in a script, this is done
before rerendering, so you don't see the image being rendered uncentered
for an instant after zooming out, before being rerendered centered.
Also update --video-align docs while at it.
This doesn't work well with --video-pan-{x,y} because you can move the
output rectangle far away from the image, and when zooming out pan is
abruptly reset to the center. It doesn't feel like natural like zooming
out after changing --video-align-{x,y}. So this commit doesn't set pan
to 0. Also this leaves a way to move scaled images within the window
even with --video-recenter.
If p->colormatrix is 0 if not set by user, so it would always override
_orig parameters with Dolby Vision ones and restore that erroneously.
Fixes: e2365bfece
Clipboard contents are available as selection data offers under
Wayland. The offer can become invalid at any time, so request the
text format content immediately when an offer is received,
and cache the content for later use.
Instead of printing circles in show-text ${playlist}, ${chapter-list}
and ${edition-list}, introduce --osd-selected-color and
--osd-selected-outline-color to reduce clutter, make the selected item
easier to differentiate, and have visual consistency with select.lua.
The defaults are taken from the style of the selected item in the
console. These new options are also used there, replacing the hardcoded
styles. Due to being user-configurable, selected item styles are changed
to take priority over default item styles.
The default selected style is yellow and bold. The bold (hardcoded)
allows differentiating the selected item with color blindness. There is
also a separate --osd-selected-outline-color option defaulting to black,
since without it if the user changes --osd-outline-color yellow text
becomes unreadable without a black border. --osd-selected-back-color is
omitted for now.
Text and background colors are inverted for the selected item in the
terminal. This is hardcoded, adding an option is overkill.
A disadvantage of this commit is that if you run print-text ${playlist}
with a VO, the selected style ASS is printed to the terminal (but ASS
printed in the console is interpreted). This commit avoids printing the
reset ASS sequence for non-selected items to reduce clutter in this
case.
It turns out mpv doesn't tag at all when doing conversions, so we just
re-tag here and hope for the best. This should be improved, but there
are many different code paths when conversion can happen, so for now
revert to previous behavior.
Fixes: 4e5cc9cf1d
If we lose the current output for any reason (unplug, turns off, etc.)
and then later it comes back, mpv should always recalculate all the
scaling stuff. The optimization to avoid needless scaling calculations
didn't consider this case and would always exit since the scaling is the
same. So just check wl->current_output's existence as well.
Fixes#15361.
Whenever mpv window gains focus, a new data offer is sent for the
selection. However, mpv currently treats it the same as dnd data
offers, which results in wrong handling. One bug which results from
this is when focus follow mouse is enabled, dropping the dnd file
results in the window being focused and selection offer being sent,
freeing the existing dnd offer. This results in dnd being broken
on at least GTK3.
Fix this by separating selection and dnd offer handling. Since there
is no way to know whether an offer introduced by
data_device_handle_data_offer is a selection or dnd offer, make it
pending, and move them once the identity is confirmed.
