add new app_bridge objc file for bridging between mpv core and app
functionality. replace old EventsResponder singleton with AppHub.
another step to clean up all App functionality and have one central
place for it.
timeBeginPeriod() only allows setting minimum timer resolution
to 1 ms. However, modern x86 platforms support a minimum timer
resolution of 0.5 ms. Use NtSetTimerResolution() instead for
the increased resolution, which can be set with MPV_HRT_RES.
Additionally, change the units of mp_start_hires_timers(),
mp_end_hires_timer(), MPV_HRT_RES, and MPV_HRT_MAX to nanoseconds,
in accordance with other functions used in timer.h.
GetConsoleMode() can be quite slow and in mpv the mode never changes, so
we can just check it once.
Fixes performance when writing lots of logs to terminal.
%s is evaluated as wchar_t only in "Windows classic" semantic. It is not
C standard compliant.
%ls is compatible with both and means the same wchar_t format.
This commit fixes error output from mpv.com.
See: https://devblogs.microsoft.com/oldnewthing/?p=102823
This is default behavior to attach to existing console, passing custom
handles is useful if we want to replace them, but in case they are
already attached to console we want to attach to console directly.
In theory, it should work out of the box because "console-like" handles
should be managed by Windows internally, which works for INPUT and
OUTPUT, but in certain cases, not for ERROR. This allows using VT
features in those cases for stderr too.
This flag is a GNU extension in C99, but was standardrized in C11,
so mpv should be able to use it. fopen is wrapped on win32 so
non-compliant MSVCRT.dll isn't a concern.
Since the upcoming commit uses this feature it can be brought back.
This reverts commit c36e051470.
only add the "Show log File…" menu item config when invoked from the
bundle, instead of testing on menu item creation. this is similar to the
touch bar menu items now.
keeping track of the dynamic menu items lets us directly access them by
key. we don't need to search in the config array for the right config
and menu item.
the check broke when the runtime check was removed, eg the menu item was
never added to the menu. since we only add the menu item to the config
when touch bar support is available the check is completely unnecessary.
the swift obj-c bridging header is only included when cocoa-cb is
enabled. cocoa-cb is not the only swift feature anymore and disabling
cocoa-cb leads to a runtime error that specific swift classes could not
be found.
include the swift obj-c bridging header in the case swift features are
enabled.
cocoa-cb was always pre-allocated in the Application itself because
libmpv needs to be set up before usage, an opengl context has to be set
and because it was decided mac specific code should be kept out of
libmpv.
this means that a completely working libmpv and opengl renderer was set
up even if it wasn't used. leading to unnecessary log message, resources
being used or reserved on the system that might not be used, triggering
of dedicated GPU unnecessarily and many other things.
even if not optimal, this wasn't the biggest problem since we only had
that one working vo on macOS. though now that we have a vulkan
gpu(-next) backend on macOS that was made the default, we always have
that dangling cocoa-cb instance, which is completely unnecessary.
move the cocoa-cb initialisation into libmpv preinit function and only
init cocoa-cb when we are a standalone App and cocoa-cb support is build
into.
unlink() was never wrapped in win32, so all usages of it were referring
the ANSI version of the function. This doesn't work properly for Windows
versions before 1903 (where the UTF-8 codepage is requested).
Fix this by adding mp_unlink() which wraps over _wunlink().
The purpose of osdep/io is to provide a wrapper for POSIX I/O functions
on Windows. The last 2 functions are utility functions which don't serve
this purpose.
Move them to a separate file.
fopen() with 'x' mode is a non-portable glibc extension, is currently
unused, and should not be used in order to maintain POSIX compatibility.
Thus there is no need for the Windows wrapper mp_fopen() to support it.
the observer is registered on every call of the start function. this
could lead to several registered observers for the same event and
several calls to the make current function, even though we only need it
once per event.
properly remove the observer on stop, so we only ever have one observer
registered.
der richter