| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases, such as when using the libmpv opengl-cb API, or with
certain vo_opengl backends, the main framebuffer is never accessed.
Instead, rendering is done to a FBO that acts as back buffer. This meant
an incorrect/broken bit depth could be used for dithering.
Change it to read the framebuffer depth lazily on the first render call.
Also move the main FBO field out of the GL struct to MPGLContext,
because the renderer's init function does not need to access it anymore.
|
| |
|
|
|
|
|
|
|
| |
Useful for testing. Unfortunately, the nVidia EGL driver ignores this,
and returns a GLES 3.2 context anyway (which it is allowed to do). Might
still be useable with ANGLE, which will really give you a GLES 2 context
if you ask for it.
|
|
|
|
|
|
|
| |
When dumb mode is used (the "simple" rendering path), respect the dither
options. Options should never be ignored (except in GLESv2 mode); either
they should be respected in dumb mode, or they should disable dumb mode.
In this case, the former applies.
|
|
|
|
|
|
|
| |
This actually fixes the dreaded errors during resizing. It works pretty
much like before, except each surface is reallocated before it's used.
It implies surfaces with the old size remain in the presentation queue
and will be displayed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't assume 0 is an invalid object handle. vdpau with its weird API
design makes all objects indexes, with 0 being a perfectly valid and
common value. You need to use VDP_INVALID_HANDLE, which is not 0.
Don't crash if init fails at vdpau initialization. It's because
mp_vdpau_destroy(NULL) crashes. Simplify it.
Destroy output surface backed FBO before output surface. Also, strictly
bookkeep the map/unmap calls (and unmap surfaces before destroying the
FBO/texture). I can't see a change in the weird errors when resizing the
window, but I guess it's slightly more correct.
Add the GL_WRITE_DISCARD_NV symbol to header_fixes.h, because we might
fail compilation with headers that do not contain the vdpau extension
(well, probably doesn't matter).
|
|
|
|
|
|
|
| |
The gl_timer_last_us() function could access samples[-1]. Fix by
coercing to unsigned, so the % will put it into index [0,max). The
real value returned in this corner case doesn't mean too much, I
guess.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As the manpage says, this has no value other than adding bugs.
It uses code based on context_x11.c, and basically does very stripped
down context creation (no alpha support etc.). It uses vdpau for
display, and maps vdpau output surfaces as FBOs to render into them.
This might be good to experiment with asynchronous presentation. For
now, it presents synchronously, with a 4 frame delay (which should whack
off A/V sync). The forced 4 frame delay is probably also why interaction
feels slower.
There are some weird vdpau errors on resizing and uninit. No idea what
causes them.
|
|
|
|
|
|
| |
Should have done this 1000 years ago. Now GL backends can use mp_log
macros directly on the MPGLContext, instead of doing stupid things like
for example MP_WARN(ctx->vo, ...).
|
|
|
|
|
|
|
| |
The function tried to do something clever but ignored the fact that
the middle button followed the left button rather than the right.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
due to the see-through nature of the title bar and our standard black
window background, the title bar appears dark grey opposed to the
expected light grey.
we change the window background to white but at the same time set the
background of the enclosed view to black. that way the title bar has a
white background and the background of our video stays black in all
cases. this prevents white flashing in some cases when the video is
resized with too heavy render settings.
|
|
|
|
| |
Fixes #4194
|
|
|
|
| |
(Helps shell completion.)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The existing code modifies f.radius so that it is in terms of the
filter sample radius (in the source coordinate space) and has
some small errors because of this behavior.
This commit changes f.radius so that it is always in terms of
the filter function radius (in the destination coordinate space).
The sample radius can always be derived by multiplying f.radius
by filter_scale, which is the new, more descriptive name for the
previous inv_scale.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modifications to the input coordinates should all be performed
before the final range check against the filter boundaries.
However, in the existing code, the blur/taper is applied after the
filter radius check is performed. Thus, effectively the filter radius
cutoff is applied to only-downscaling-metric-modified coordinates, not
the final coordinates.
Correct this issue and restructure the returns a bit to make it
more obvious what is being done.
|
|
|
|
|
|
|
|
|
|
|
| |
forcibly moving a window from one screen to another is supposed to put
it in a position that looks relative the same as on the old screen, as
in bottom, top, left and right margin look the same, without changing
the window size. in some situations the old code moved the window off
screen or on top of the menu bar so it ended up at a somewhat random
position. the new code fixes some edge cases but is probably not
completely correct since the priority is to make sure that the window
ends up on the right screen.
|
|
|
|
|
|
|
|
|
|
|
| |
when forcibly moving windows to a different screen with --screen or
--fs-screen we need to move the window into the screen bounds if the
window is out of bounds, otherwise it can end up on the wrong screen.
previously it always recalculated the bounds and moved the window when
toggling fullscreen, now it only does the bound calculation when
changing screens.
Fixes #4178
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
i falsely assumed that the windowDidChangeScreen was meant to report
‘physical’ screen changes but was wondering why it triggers on other
events too. it actually is a event that informs us when anything
referenced by our current NSScreen is changed. even when something
referenced in the NSScreen changed the old and new NSScreen are still
equal if the physical screen didn’t change. with that my previous
optimisation broke some cases where the physical screen didn’t change
but things it referenced did, leading to a segfault when theses were
accessed. to keep the optimisation we will always update our internal
NSScreen reference but the rest only when the physical screen was
changed.
|
|
|
|
| |
Fixes #3242
|
| |
|
|
|
|
|
|
|
|
| |
What a fucking waste of time. It depends on with which headers you
compile as well, so the situation is worse and more confusing than
you'd think. God knows what brain fart made them change the numeric
ID without changing the extension name or any other ways to keep
ABI-compatibility and without any warning.
|
|
|
|
|
|
| |
Locale-independent, and doesn't have the char vs. unsigned char problem.
(Although in this case, the code was fine, because bstr.start is
unsigned char.)
|
|
|
|
|
|
|
|
|
|
| |
fffab30 introduced a small regression where the cursor couldn't be
unhidden after refocusing. the problem is that no mouseUp event was
reported in our events_view. work around this with a separate event
monitor. this also fixes another regression when the window is being
dragged from the title bar.
#4174
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a race condition created by the previous commit, and possibly
others. Sometimes interpolated frames weren't redrawn as uninterpolated
ones.
The problem is that redrawing/drawing a frame can't reset the VO
want_redraw flags, because logically these have to happen after the core
acknowledged and explicitly reissued a redraw. The core needs to be
involved because the OSD text and drawings could depend on the playback
or window state.
Change it such that it always goes through the core.
Also, VOs inconsistently called vo_wakeup() when setting want_redraw,
which is also taken care of by this commit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When pausing, we sent BOCTRL_PAUSE and VOCTRL_RESTORE_SCREENSAVER. These
essentially wait until the video frame has been rendered. This is a
problem with the opengl-cb, if GL rendering is done in the same thread
as libmpv uses. Unfortunately, it's allowed to use opengl-cb this way.
Logically speaking, it's a deadlock situation, which is resolved with a
timeout. This can lead to quite ugly effects, like the on-pause frame
not being rendered until the timeout has passed. It has been interpreted
as video continuing to play.
Resolve this by simply not blocking on pause. Make the screensaver
controls async, and handle sending VOCTRL_PAUSE in the VO thread.
(All this could be avoided by redoing the internal VO API.)
Also see #4152.
|
|
|
|
|
|
| |
even though the mouse doesn’t move relative to the window itself, when
the window is being dragged, some outliers are still reported and
trigger the OSC.
|
|
|
|
|
|
| |
fixes the case when mpv is opened and the cursor is within the window
bounds without moving the mouse. previously the window could only be
dragged around after the first mouse movement.
|
| |
|
|
|
|
| |
They're unrelated. Sue me.
|
|
|
|
|
|
|
|
|
| |
This was a hack to let libmpv API users pass a d3d device to mpv. It's
not needed anymore for 2 reasons:
1. ANGLE does not have this problem
2. Even native GL via nVidia (where this failed) seems to not require
this anymore
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
even before the recent refactor the cursor was hidden when moving it to
the top of the screen in fullscreen and placing it on top of the now
visible menu bar.
we need to know when the menu bar is hidden so we don’t create a
‘dead zone’ at the top of the screen where the cursor can’t be hidden.
to determine when the menu bar is visible, and with that the title bar,
we get the height of the menu bar. the height is always 0 when hidden.
furthermore there is no way to get the title bar directly and with that
its height. so we calculate the frame rect of a NSWindowStyleMaskTitled
window from a CGRectZero content frame. the resulting height is the
height of a title bar.
with that we can exclude the top area for the cursor hiding and can be
certain when the menu bar is not hidden.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the cursor couldn’t be hidden when the cursor was at the same position
as the Dock, even if the cursor was next to it. this is especially
annoying in fullscreen since the Dock isn’t actually hidden but is still
reported as being visible. this basically made the part of the screen,
where the Dock resides, a ‘dead zone’. so instead of using the
visibleFrame we will just use the normal frame. there is no problem at
the top area of the screen, since a window can’t be placed above the
menu bar and in fullscreen the menu bar is always reported as not being
on screen.
i suspect this was done so the cursor wasn’t hidden when the it was
placed above the Dock when windowed. with the recent refactor this is
not needed any more.
|
|
|
|
|
|
|
|
|
|
| |
we can simplify the code because we don't need to change the bool
pointer we were given by the VOCTRL_SET_CURSOR_VISIBILITY event. i
assume this was done to work around some bugs previously to the recent
cursor refactor. i kept that because i thought it was necessary, which
wasn't in the end. after the refactor it only caused some weirdnesses i
tried to work around. without it we can get rid of some special cases
and simplify the code quite a bit.
|
|
|
|
|
|
|
| |
holding shift swaps the scroll wheel axes and deltaY returned zero.
summing up deltaX and deltaY will always give us the right button.
Fixes #3506
|
|
|
|
|
|
| |
Implements --hwdec=videotoolbox on iOS. Similar to hwdec_osx.c, but
using CVPixelBuffer APIs available on iOS instead of the equivalent
IOSurface APIs in macOS.
|
|
|
|
| |
Regression from recent refactor.
|
|
|
|
| |
Plus add a helper.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can drop the custom table.
For some reason, the interop does not accept GL_RGB_RAW_422_APPLE as
internal format for GL_RGB_422_APPLE, so switch the format table to use
GL_RGB (this way both interop and real textures work the same).
Another victim of the apparent requirement of exactly matching texture
formats is kCVPixelFormatType_32BGRA. vo_opengl wants to handle this as
normal RGBA texture, with a swizzle applied in the shader.
CGLTexImageIOSurface2D() rejects this, because it wants the exact
internal format. Just drop the format, because it's useless anyway.
(Maybe this is a bit too fragile...)
|
|
|
|
| |
Gives us automatically support for all formats vo_opengl supports.
|
|
|
|
|
|
|
| |
All supported pixel formats have a specific "mapping" of CPU data to
textures. This function determines the number and the formats of these
textures. Moving it to a helper will be useful for some hardware decode
interop backends, since they all need similar things.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GL_LUMINANCE_ALPHA is the only reason why per-plane swizzles exist.
Remove per-plane swizzles (again), and regrettably handle them as
special cases (again). Carry along the logical texture format (called
gl_format in some parts of the code, including the new one).
We also don't need a use_integer flag, since the new gl_format member
implies whether it's an integer texture. (Yes, the there are separate
logical GL formats for integer textures. This aspect of the OpenGL API
is hysteric at best.)
This should change nothing about actual rendering logic and GL API
usage.
|
|
|
|
|
| |
Wrong colors. This didn't matter for the OpenGL interop code, because
the CV format was mapped to the correct texture format.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Originally, there was probably some sort of intention to restrict it to
formats supported by the interop, or something. But in the end it was
overcomplicated nonsense.
In the future, we could use mp_hwdec_ctx.supported_formats or other
mechanisms to handle this in a better way.
mp_hwdec_ctx.ctx is not set to a dummy pointer - hwdec_devices_load() is
only used to detect whether to vo_opengl interop is present, and the
common hwdec code expects that the .ctx field is not NULL.
This also changes videotoolbox-copy to use --videotoolbox-format,
instead of the FFmpeg-set default.
|
|
|
|
|
|
|
|
| |
The code for copying a videotoolbox surface to mp_image was duplicated
(with some minor differences - I picked the hw_videotoolbox.c version,
because it was "better"). mp_imgfmt_from_cvpixelformat() is somewhat
duplicated with the vt_formats[] table, but this will be fixed in a
later commit, and moving the function to shared code is preparation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
we reported some unnecessary mouse movements and not all mouse enter
and leave events. that lead to wrongly reported activity on hover areas
like on the OSC or comparable lua scripts. sometimes menu items were
shown that shouldn't be shown or they didn't vanish because of the
missing mouse leave event.
this incorporates @torque's fix for mouse leave events that weren't
triggered during a transition, like going to fullscreen. the
tracking area was updated but the mouse never left that area because
it was never over it.
besides some known cursor visibility bugs the aforementioned changes
also revealed some other bugs that weren't reproducible before because
of the missbehavior.
known issues, in some cases the cursor doesn't show or hide properly.
for example when switching spaces, switching Apps via CMD+Tab or a
system notification. former two could be fixed while keeping our current
blank cursor approach. though the notification case couldn't. there is
no event or similar to detect a notification and the cursor visibility
couldn't be recovered in any way.
new issues, i noticed that our event view isn't initialised yet when the
first VOCTRL_SET_CURSOR_VISIBILITY event gets dispatched, which depends
on the event view to be initialised. so the mouse cursor couldn't be
hidden when mpv was opened and the cursor was within the window bounds.
this wasn't noticeable before because of various bugs and unwanted
behavior that have been fixed with this. now, in case the event view
isn't ready yet, we set the visibility at a later point when the event
view is ready and a helper flag is set.
Fixes #1817 #3856 #4147
|
| |
|
|
|
|
|
|
|
|
| |
this fixes a small bug with black edges on live resize, due to the
synchronisation with the DisplayLink. we just pause the DisplayLink for
the duration of the live resize. i also added some convenience functions
for reoccurring calls and simplified some DisplayLink related screen
info.
|
|
|
|
|
|
|
|
|
|
| |
since there are different views on what ontop is, we make the ontop
window level modifiable. at the moment only support for macOS was added.
the default for macOS was changed from 'system' to 'window' since this
fixes an unwanted behaviour in fullscreen and in general causes less
issues with expected behaviour.
Fixes #2376 #3974
|
|
|
|
|
| |
If a maximized window restored from fullscreen,
the fullscreen state needs to be updated manually.
|
|
|
|
|
| |
This should be useful for debugging, since otherwise it's hard to tell
which implementation has been auto-detected or if any failed to init.
|
|
|
|
| |
Whoops. Fixes #4119
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This replaces the old backend that exclusively used EGL windowing with
one that can also use ANGLE's ability to render to directly to a
texture. The advantage of this is that it allows mpv to create the swap
chain itself and this allows mpv to use a flip-mode swap chain on a HWND
(which avoids problems with DirectComposition) and to use a longer swap
chain that has six backbuffers by default (which reportedly fixes
problems with rendering 24fps video on 24Hz monitors.)
Also, "screenshot window" should now work on DXGI 1.2 and up (Windows 8
and up.)
|
|
|
|
|
|
|
|
| |
when the color profile was changed it used the right NSScreen but with
the old colorSpace. this was optimised out by a previous commit because
of a wrong assumption. we need to update the screen so we can get the
new colorSpace. this adds a bit of redundancy since on screen change it
will update screen pointer twice.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the problem here is that dropped files can also be treated as
NSURLPboardType instead of just NSFilenamesPboardType. the 'else if'
could never be reached and was dead code.
this basically reverts ed695ce which tried to fix multiple dropped
URLs, or rather files, and moves the filename check infront of the URL
check. the filename path can handle multiple dropped files, whereas the
URL path can only handle one dropped URL. this assumes that only one URL
can be dropped at a time. it also reverts a603543 because it's not
needed any more.
this also fixes a problem where dropped URLs from Chrome don't conform
to the NSURL class and the readObjectsForClasses metho |