summaryrefslogtreecommitdiffstats
path: root/player/lua/osc.lua
Commit message (Collapse)AuthorAgeFilesLines
* osc: more frequent cache updates: from 10% diff to 5% or 5sAvi Halachmi (:avih)2020-01-141-2/+2
| | | | | | | | 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.
* osc: usability improvements for pseudo-csd title barPhilip Langdale2020-01-131-4/+21
| | | | | | | | | | | | | | | | | | | 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.
* osc: when fullscreened, un-maximise window control should un-fullscreenPhilip Langdale2020-01-121-2/+8
| | | | | | | | | | | | | | | 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.
* osc: don't delay updates on resizewm42020-01-081-4/+19
| | | | | | | | | | | 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.
* osc: reset input handling state on a change in visibility modePhilip Langdale2020-01-021-0/+7
| | | | | | | | | | | | | | | | | 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.
* osc: redraw on visibility option runtime changeswm42019-12-241-0/+1
| | | | | | This affects behavior when using the "del" default key binding. Sometimes, setting visibility to always did not draw it correctly. This probably fixes it.
* osc: add option to disable santa hatNicolas F2019-12-231-2/+3
| | | | | | | | | | 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.
* osc: set an arbitrary high Z-orderwm42019-12-231-0/+1
| | | | | | | | 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.)
* osc: use new overlay APIwm42019-12-231-5/+18
| | | | | | | | | 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.
* osc: display Santa hat for idle logo in DecemberTheAMM2019-12-231-18/+43
| | | | | | | | | | 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>
* osc: use video margins only if OSC is visiblewm42019-12-221-6/+5
| | | | | Looks awkward otherwise. This means that even if boxvideo is enabled, nothing gets "boxed" if the OSC is set to auto-hide.
* osc: cleanup boxvideo margin handlingwm42019-12-221-20/+23
| | | | | | | | | | 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.
* osc: full reinit on runtime option changeswm42019-12-221-3/+2
| | | | | | | | | 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.
* osc: cosmetics: remove some excessive whitespacewm42019-12-201-7/+0
|
* osc: react to script-opts runtime changeswm42019-12-201-1/+8
| | | | | | | | | | 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
* osc: rearrange hidetimeout/visibiltiy handlingwm42019-12-201-19/+19
| | | | | | | | | | 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.
* osc: move windowcontrols option code to the right placewm42019-12-201-15/+14
| | | | | | 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.
* osc: fix a commentwm42019-12-201-1/+1
|
* osc: fade out if paused and mouse position is outside of OSCwm42019-12-191-5/+18
| | | | | This broke with the recent changes since tick() is not called regularly anymore in paused mode. Add an explicit timer for this.
* osc: fix crash when toggling visibilitywm42019-12-191-1/+0
| | | | | The previous osc.lua related commit removed this function, and trying to call it crashed the OSC. Just remove the call.
* osc: don't run update_margins() every framewm42019-12-191-2/+4
| | | | | This is something recent that also caused per frame log spam, because it tried to update the margins every frame.
* osc: use property notifications and a timer instead of "tick" eventswm42019-12-191-60/+47
| | | | | | | | | | | | | | | | | | | | | | | 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.)
* osc: make margins availablewm42019-12-181-1/+23
| | | | | | | | | 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.
* osc: set the wrap style for the title shown with window controlsPhilip Langdale2019-12-121-1/+1
| | | | | | 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.
* osc: use custom symbols for window controlsPhilip Langdale2019-12-111-10/+26
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* osc: explicitly re-init the osc on a change in border visibilityPhilip Langdale2019-12-091-0/+1
| | | | | | | | | | | | | | 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.
* osc: rework window control configuration to add auto modePhilip Langdale2019-12-041-17/+46
| | | | | | | | | | | | | | | | 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.
* osc: ensure that window control show/hide zone is handled dynamicallyPhilip Langdale2019-12-041-6/+6
| | | | | | | | | | | | | | | | | | | 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.
* osc: don't show error if windowcontrols=yesPhilip Langdale2019-12-021-1/+2
| | | | | | | | 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".
* osc: don't always set window control keybindingsDudemanguy2019-12-011-4/+6
| | | | | Only set the window control keybindings if the window control option is actually enabled. Fixes #7212.
* osc: ensure the window-controls mouse area is initially zero sizedPhilip Langdale2019-11-301-0/+1
| | | | | | 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.
* osc: fix typo wsc_geo -> wc_geoPhilip Langdale2019-11-301-1/+1
|
* osc: apply boxvideo margins to the window controlsPhilip Langdale2019-11-301-0/+3
| | | | | | 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).
* osc: fix operation when window controls are disabledwm42019-11-291-2/+4
| | | | | It seems this area is simply not defined when window controls are disabled, so ipairs() will crash on it.
* osc: handle deadzone and barmargin for window controlsPhilip Langdale2019-11-291-6/+28
| | | | | | | | | | | | | | | | 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.
* osc: implement pseudo client side decorations via OSCPhilip Langdale2019-11-291-7/+145
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 functionality that we already have. The main work here is defining a separate input area from the main OSC box with its own buttons, etc. While we could probably handle auto-detection based on whether decorations are present or not, it's manually controlled for now. The window control logic is mostly disconnected from the OSC itself, except in the case of the `topbar` layout, where there has to be coordination so that the controls don't get drawn on top of each other. I had to do fine-positioning of the buttons based on the font on my system, so don't be surprised if it looks wrong elsewhere. You could also argue that window controls should be unscaled, even if the main OSC box is scaled, but I've not tried to do this.
* osc: calculate osc_geo position after aspect correctionJan Janssen2019-10-291-6/+8
| | | Fixes #7098
* osc: Unify bottom and topbar codeJan Janssen2019-10-281-179/+31
| | | | | | Among the pointless duplication the right timecode label was given some extra space that wasn't needed. Fixes: #6904
* osc: add mouse mid-button as alias to shift+left buttonRicardo Constantino2019-09-211-0/+3
|
* osc: add feature to bottombar to not cover the videowm42019-09-191-1/+47
| | | | | | | | | | | | | | | | | | | | | | Normally I use the OSC like this: not at all, but have a key binding that does "cycle osc" to show it. And in that case, I don't really want it to overlap the damn video. I could use the zoom/pan options to move the video out of the way, but this is also sort of annoying. Likewise, you could write a script or so which does this automatically if the OSC appears, but that's still annoying, and computing values for these options such that the video is moved correctly is tricky. So I added a bunch of options that set explicit video borders (previous commit), and a option for the OSC to use them (this commit). Disabled by default, since I'm afraid this is too awkward and unpolished, especially with OSC default settings. I'm also using "osc-visibility=always". Effectively, making the OSC appear will box the video, and making it disappear (by unloading osc.lua) will restore the video back to normal.
* osc: improve look of seekrangesJan Janssen2019-09-021-78/+185
|
* osc: fix accidentally skipping files when seeking with sliderfatalis2018-06-041-0/+2
| | | | | | | When seeking near the end of the file and the next file loads, seeking continues on the next file at the same position and then immediately the file after that. This patch stops slider seeking when a new file is loaded, which is the standard behavior of many other players.
* osc: leave only demuxer cache duration and limit its refresh rateRicardo Constantino2018-01-141-19/+16
| | | | Sorta requested in #5390
* osc: add seekbarkeyframes as a user optiondudemanguy2018-01-031-2/+3
|
* osc: check if demuxer cache has not reached eofRicardo Constantino2018-01-021-3/+3
| | | | Avoids flickering stream cache status while filling the demuxer cache.
* osc: hide cache if not forced for local filesRicardo Constantino2017-12-261-13/+7
| | | | | Also hide cache if 'cache-used' is 0 (usually means video fits entirely within demuxer-cache-duration or stream cache is disabled).
* osc: make seek ranges rendering optionalpavelxdd2017-12-261-0/+4
| | | | | This commit adds a new osc setting `seekranges` to control the seek ranges visibility.
* osc: show demuxer cache buffered amount in byteswm42017-12-231-2/+6
| | | | | | | | Same as previous commit, but for the OSC. (A bit of a waste to request demuxer-cache-state at least twice per frame, but the OSC queries so many properties it probably doesn't matter anymore.)
* msg: reinterpret a bunch of message levelsNiklas Haas2017-12-151-7/+7
| | | | | | | | | | | | | | | | | | | | | | I've decided that MP_TRACE means “noisy spam per frame”, whereas MP_DBG just means “more verbose debugging messages than MSGL_V”. Basically, MSGL_DBG shouldn't create spam per frame like it currently does, and MSGL_V should make sense to the end-user and provide mostly additional informational output. MP_DBG is basically what I want to make the new default for --log-file, so the cut-off point for MP_DBG is if we probably want to know if for debugging purposes but the user most likely doesn't care about on the terminal. Also, the debug callbacks for libass and ffmpeg got bumped in their verbosity levels slightly, because being external components they're a bit less relevant to mpv debugging, and a bit too over-eager in what they consider to be relevant information. I exclusively used the "try it on my machine and remove messages from MSGL_* until it does what I want it to" approach of refactoring, so YMMV.
* osc: make cycling visibility an input.conf key bindingwm42017-11-031-1/+1
| | | | | As builtin script, it should not register global key bindings, and add them to input.conf instead. This is similar to what stats.lua does.
* osc: render seek ranges a bit less uglyChrisK22017-11-021-1/+1
|
* osc: render seek rangeswm42017-11-021-0/+26
| | | | | | Pretty fucking ugly, but I'm not a UI designer. Of course only does something with --demuxer-seekable-cache.
* osc: fix rare stack overflow when changing visibility modeAvi Halachmi (:avih)2017-09-231-1/+6
| | | | | | | | | | | | | Under some conditions, hide_osc() was calling render(), which then called hide_osc() again, and so forth, until the stack overflows. Tracking the exact conditions where this happens (and then managing them to prevent it) is an excercise in futility. Remove the osc directly - instead of going through the entire rendering procedure just to end up rendering nothing. Fixes #4900 .
* input: merge mouse wheel and axis keycodesJames Ross-Gowan2017-09-031-2/+0
| | | | | | | | | | | | | | | | | | | | | |