| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
osc-visibility can already be changed at runtime via script-message
or other means, but until now there was no way to tell what the
current state is.
Now shared-script-properties/osc-visibility reflects this state.
It's output-only by the osc - changing it does not affect the osc.
Useful if a script wants to change osc-visibility temporarily, and
later restore to its original state.
There's no way to coordinate if more than one script wants to change
it, but that would be a hard problem to solve anyway, even if the
osc itself tried to coordinate such requests from different sources.
|
| |
|
|
| |
Fixes #8925
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously tick() was ensured unconditionally only after mouse-move,
but there are other mouse-events which need re-rendering (tick), like
mouse-down (icons may get grayed-out) or mouse-up (icons may change).
For instance: mpv --pause --myclip.mkv
then move the mouse over the volume/mute OSC button, then - without
moving the mouse - press and release the left mouse button.
The osc was not re-rendered because it's paused and the mouse didn't
move, so the volume icon didn't get grayed-out when held down, and the
icon doesn't change on mouse-up (to reflect the new mute state).
Now both these changes are rendered correctly.
|
| |
|
|
|
|
|
|
|
| |
This is not a new issue, however, until the last commit - 96b246d
init probably didn't happen much (or at all) between mouse-down and
mouse-up, but after this commit, if there are chapters in a live-stream
then osc_init() is used to re-render the markers at the adjusted
position - which breaks the OSC buttons functionality if init happened
between mouse-down and mouse-up.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 6abb7e3 updates the markers when the chapters change, but it
doesn't update their relative position at the bar when the duration
changes.
This means that adding chapters to a live stream would result in
corresponding chapter markers which were static while the duration
changed and thus their positions became incorrect over time until the
OSC was reinitialized.
This is fixed by observing the duration property if chapters are present
and reinitializing the OSC when the duration changes.
The live_markers user option, which determines whether the duration
property is observed when there are chapters, has been added in order to
allow disabling this behaviour as calling request_init() frequently
might have some impact on low-end systems.
The impact of request_init() on render() was measured to increase from
1-1.5 ms to 2-3 ms on a 2010 MacBook Air, while the impact was neglible
on a 2016 Surface Book (increasing only to an average of 1.4 ms from
1.3 ms for n=1500 render cycles).
The live_markers option is enabled by default.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When the OSC initializes, it checks whether the current video has
chapters, and if it does not, it disables its chapter functionality
(chapter buttons are grayed out and unusable, chapter indicators don't
show on the seek bar). If another script changed the chapter list
after the video has loaded, those changes would be ignored by the OSC
until some other event causes it to re-initialize, because it did not
observe the chapter list property. This is fixed by adding
observation of chapter-list alongside the other properties that
trigger re-initialization.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug where using boxvideo with showfullscreen=no or
showwindowed=no resulted in the margins not resetting when the OSC
wasn't visible.
For example, using:
script-opts=osc-visibility=always,osc-boxvideo=yes,osc-showfullscreen=no
and then going fullscreen would make the OSC disappear but the video
margins would remain. This is because boxvideo was missing a dependence
on the showfullscreen and showwindowed user options.
This is fixed by adding the corresponding conditions to update_margins()
and setting state.marginsREQ on fullscreen changes. update_margins() is
called on tick() if there's a margins update pending, which guarantees
the boxvideo margins are reset appropriately.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clearing state.osd.data with an empty string at render_wipe() fixes an
issue where changing the OSC visibility from "never" directly to
"always" didn't immediately update the display when the player was
paused. This could be verified by starting the player with
`--script-opts=osc-visibility=always --pause` and then running
`script-message osc-visibility never` followed by
`script-message osc-visibility always`.
Removing the overlay without changing the contents meant the overlay
wouldn't update and display when enabled again until the fields changed
in some way (e.g. seeking, mousing over the OSC area, etc.). Clearing
state.osd.data before removal of the OSC makes sure set_osd doesn't
return on re-enable and instead displays the OSC immediately as the data
is now different.
render_wipe() is now also used when the OSC needs to be cleared at
tick() as using set_osd to clear it with an empty string did not call
state.osd:remove() which can allow cleanups related to bitmap memory
allocations etc.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The OSC calls this "tooltip" (and although a general mechanism, there's
only one instance using it). One particular problem was that with the
default OSC layout, moving the mouse down and out of the window, the
tooltip stuck around, because the returned mouse position was the last
pixel row in the window, which still overlaps with the seek bar.
Instead of introducing mouse_in_window, you could check last_mouse_X for
nil, but I think this is clearer.
This returns (-1, -1) to the caller if the mouse is outside. Kind of
random, but works.
|
| |
|
|
| |
The new code is pretty much equivalent.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The message_timeout field was basically polled. But ever since the OSC
was changed to work more event based, this didn't quite work. It was
quite visible when switching subtitle or audio tracks while paused (and
with caching disabled, since the cache update triggered some extra
redrawing).
Fix by using a proper timer.
I noticed that changing tracks with the message call commented didn't
redraw properly either, but, uh, I guess the message is always triggered
anyway, and happens to take care of this.
|
| |
|
|
|
|
|
| |
The "seekbarkeyframes" option is now interpreted such if it's true, the
player default is used. Too lazy to make this a choice option or
whatever; the Lua option parser doesn't have support for that anyway.
Someone who cares can adjust this.
|
| |
|
|
| |
Avoids an additional property access; see previous commit.
|
| |
|
|
|
|
|
|
| |
Cache display updates, especially when it's bigger than few minute,
could have been be very infrequent to the point that one is not sure
if it updates at all.
Reduce the 10% change-threshold to 5% and add another threshold of 5s.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are two improvements here:
1) Correct the right-side padding on the title box. This was messed
up previously because I was passing the title box width when I
should be passing the x coordinate. I've also increased the
spacing to separate the title from the window controls more
clearly.
2) I'ved added a mouse tracking area over the title bar so that the
osc doesn't disappear if you hover over the title box. This didn't
work previously because the input area only covers the actual
window controls. The implementation here is simplified in that
it's only a mouse area and not an input area. This is enough to
keep the osc visible, but it won't stop the mouse pointer
disappearing. Fixing that requires a full input area which, for
now, I will say isn't worth the effort.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's a bit unintuitive today when you use the un-maximise control
while fullscreened. Depending on the VO in use, this might silently
change the maximise state without any visible effect, or it might
do nothing. It's less surprising if the control exits the fullscreen
state.
Note that the exact behaviour is still VO dependent. If the window
was maximised before being fullscreened, it might exit fullscreen
back to maximised or back to regular window mode.
I thought about trying to explicitly control that behaviour but
it makes the osc code weird and probably wouldn't work all the time.
|
| |
|
|
|
|
|
|
|
|
|
| |
The idea is that if the player is resized, we do not delay redrawing
(which is normally done to limit the redraw rate to something
reasonable).
Not sure if this even does anything. For one, reacting to osd-dimensions
changes is cleaner than just polling the screen size with the next tick
event, and hoping that resizes generate tick events for whatever
logically unrelated reasons.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the activation and deactivation of input handling is done
inside the render() loop, but this does not run when the osc mode is
`never` - which does make sense.
That means that if you are cycling the visibility mode, the input
state will be whatever it was at the time of the mode change. And,
as our modes are ordered `auto` -> `always` -> `never`, the input
state will be enabled when you cycle to `never`.
There are various ways you can imagine fixing this, and in this
change I propose we reset the input state to disabled on a mode
change, and then let render() re-enable input if that's appropriate.
Fixes #7298.
|
| |
|
|
|
|
| |
This affects behavior when using the "del" default key binding.
Sometimes, setting visibility to always did not draw it correctly. This
probably fixes it.
|
| |
|
|
|
|
|
|
|
|
| |
A minority of users have expressed a dislike of hats, calling them
"cancer [that] don't belong in software" describing the people who add
them as "shitty circlejerks" and "chucklefuck."
While I personally disagree with those opinions, it's probably easier
to let them have it their way. For that reason this adds the option
`greenandgrumpy` to the osc, which allows users to disable the hat.
|
| |
|
|
|
|
|
|
| |
The main reason for this is just to make show the OSC always above
console.lua, instead of a random order.
(And this is also the only reason osc.lua was changed to the new API.
The old API could have been extended, but lets not.)
|
| |
|
|
|
|
|
|
|
| |
This tries to avoid the update() call if nothing changed. This brings it
more into line with the old code (the osd-overlay command simply does
not skip the update if nothing changed). I don't know whether this
matters; most likely not. Normally, code should try to avoid redundant
updates on its own, so it's not the job of the command. However, for the
OSC we simply want to reduce the differences.
|
| |
|
|
|
|
|
|
|
|
| |
During the 12th month (checked during script initialization), draw a Santa hat
on top of the idle message's logo.
Slightly refactors and optimizes the drawing process as well: reorder original
logo layers and remove redundant holes in them, use a shared line prefix
to clear the style and set start position.
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
|
| |
Looks awkward otherwise. This means that even if boxvideo is enabled,
nothing gets "boxed" if the OSC is set to auto-hide.
|
| |
|
|
|
|
|
|
|
|
| |
Make sure it gets properly reinitialized when needed. This is especially
useful now that the OSC reacts to runtime option changes, which can
change the layout too.
This may call set_property_number() on the margin properties more often
now, but since redundant option changes are ignored now, this shouldn't
have any too bad effects.
|
| |
|
|
|
|
|
|
|
| |
Fuck it, just let's just reinit everything.
On a side note, the changelist parameter provided by read_options()
(here "list") is now unused. But it's not hard to provide and might be
useful for other stuff. So don't remove it from the generic
read_options() code.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
With special attention to changing osc-visibility. Untested, although
osc-visibility works (it's pretty much equivalent to the key binding, so
there is not much interesting going on).
Somewhat inspired by code posted by github user CogentRedTester.
Fixes: #4513
|
| |
|
|
|
|
|
|
|
|
| |
The way how this modifies and backups/restores user option values is a
bit of a problem for runtime option changing.
Clean this up a little. Now cycling the visibility updates the user
option value, but always to "valid" values (unlike hidetimeout used to
be used). If the user option value is changed externally (enabled by a
later commit), it'll be cleanly overwritten.
|
| |
|
|
|
|
| |
There doesn't seem to be a reason why it was where it was. It should be
in validate_user_opts(), which will be important for runtime changing
too.
|
| | |
|
| |
|
|
|
| |
This broke with the recent changes since tick() is not called regularly
anymore in paused mode. Add an explicit timer for this.
|
| |
|
|
|
| |
The previous osc.lua related commit removed this function, and trying to
call it crashed the OSC. Just remove the call.
|
| |
|
|
|
| |
This is something recent that also caused per frame log spam, because it
tried to update the margins every frame.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Traditionally, the OSC used mpv's "tick" event, which was approximately
sent once per video frame. It didn't try to track any other state, and
just updated everything.
This is sort of a problem in many corner cases and non-corner cases. For
example, it would eat CPU in the paused state (probably to some degree
also the mpv core's fault), or would waste power or even throw errors
("event queue overflows") on high FPS video.
Change this to not using the tick event. Instead, react to a number of
property change events. Rate-limit actual redrawing with a timer; the
next update cannot happen sooner than the hardcoded 30ms OSC frame
duration. This has also the effect that multiple successive updates are
(mostly) coalesced.
This means the OSC won't eat your CPU when the player is fucking paused.
(It'll still update if e.g. the cache is growing, though.) There is some
potential for bugs whenever it uses properties that are not explicitly
observed. (In theory we could easily change this to a reactive concept
to avoid such things, but whatever.)
|
| |
|
|
|
|
|
|
|
| |
This is for console.lua (see next commit). The idea is that console.lua
can adjust its offset to the bottom of the window by the height of the
OSC.
If the OSC is not set to permanently visible, export no margins, because
it would look weird to move the console depending on the mouse movement.
|
| |
|
|
|
|
| |
I missed adding this when defining the style used for the video
title in the window control bar. The default behaviour is to wrap,
but we want to cut the title off when we run out of space.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I was recently informed that unicode has official symbols for
window controls, and I put together a change to use them, which
worked, as long as a suitable font was installed. However, it's
not that hard to get a normal system that lacks an appropriate
font, and libass wants to print warnings if the symbols aren't
in the default font, which will almost always be true.
So, I gave up and added the symbols to the custom osd font that
we already have. This ensures they are always available, and
that they are aligned consistently on all platforms.
I took the symbols from the `symbola` font, as this has a suitable
licence and the symbols look nice enough.
Symbola Licence:
Fonts are free for any use; they may be opened, edited,
modified, regenerated, packaged and redistributed.
Finally, as we now have access to an un-maximize symbol, I added
logic to use it when the window is maximized.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
I had previously wondered whether to do this, but in my testing
with x11 and wayland, the osc was being re-inited on a border
toggle already so I didn't add it.
However, on win32, things are different and there is no re-init
when toggling borders. I belive this is because the active window
size doesn't change in anyway, while on x11/wayland, toggling the
border actually changes the window size - and that trigger a re-init.
So, let's just be explicit and request a re-init when the border
is toggled.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To aid in discoverability, and to address the most common case
directly, I'm adding an 'auto' mode for the window controls. In
this case, we will show the controls if there is no window border
and hide them if there are borders. This also respects the option
being toggled at runtime.
To ensure that it works in the wayland case, I've also made sure
that the wayland code explicitly forces the option to false if
decoration support is missing.
Based on feedback, I've split the config in two, with one option
for whether controls are active, and one for alignment. These are
new enough that we can get away with ignoring compatibility.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As preparation for adding the auto mode for window controls, we need
to make sure that the controls can be successfully toggled at runtime,
rather than only being able to configure them once at startup. Right
now, there is a problem with the handling of the show/hide zone for
the window controls.
The previous fix for #7212 was to avoid registering the input mapping
for the window control show/hide zone. If there is no input mapping,
then there is no input, and the zone is a no-op, even if it exists.
But this only happens at startup. After that point, the input mapping
doesn't exist and cannot be turned on.
In this change, I'm switching the approach; we now go back to always
registering the input mapping, and instead, we zero out the show/hide
zone if window controls are disabled, and set its size appropriately
if they are enabled.
|
| |
|
|
|
|
|
|
| |
I always intended for this to be accepted and mean "right" but I
made it show an error for any value that's not explicitly
recognised (while considering all unrecognised values to mean "right").
So let's explicitly recognise "yes".
|
| |
|
|
|
| |
Only set the window control keybindings if the window control option is
actually enabled. Fixes #7212.
|
| |
|
|
|
|
| |
This is necessary to avoid breaking input behaviour in the 'idle'
state when not playing a video. Otherwise, the mouse area starts off
covering the whole window and blocks normal input.
|
| | |
|
| |
|
|
|
|
| |
It seems logical to account for the window controls if `boxvideo`
is in use (which has the effect of reducing the size of the video
so that the osc is not covering the video).
|
| |
|
|
|
| |
It seems this area is simply not defined when window controls are
disabled, so ipairs() will crash on it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I missed these due to only testing with my personal osc config.
The deadzone needs to be correctly handled for the window controls,
or they will fail to appear when the mouse is close to or over them.
In the process of doing that, I realised that the controls should
respect the barmargin, if set. This is because the controls should
remain aligned when layout=topbar and as the control bar is top
aligned, it should be equally affected if the user needs to set
the barmargin.
I also fixed a mistake in trying to the use the mpv-osd-symbols font
for the window controls.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Today, if window decorations are not present, either because they were
disabled, or because the platform doesn't support them
(eg: gnome-shell on wayland), there are no window controls, meaning it
is not possible to minimize/maximize/close a window without knowing
keyboard shortcuts.
While you can imagine various ways of offering client side decorations,
it is attractive to consider using OSC because that is func |
