we keep track of the current vo struct to flag for events that are
initiated async by various thread from different system notifications.
the problem here is the usage of that vo struct after uninit.
make accessing of that vo struct atomic and clear it on uninit, so it
can't be used afterwards by concurrent threads from system
notifications or events.
Fixes#15088
c4e8c36071 made any usage of --geometry
implicitly center the window on the screen after a resize even if the
user did not pass any x/y arguments to the option. At the time, this was
probably wanted since --geometry was primarily a startup option and
likely the window wouldn't be centered on x11 without moving
coordinates. Times have changed since then and we support full runtime
--geometry changes on all the relevant platforms but it comes with this
automatic window centering behavior (except on wayland of course hah).
It's better to make such window centering optional and user controllable
since it is entirely reasonable that someone wants --geometry=50% to
just resize and not move anything. It's already trivial for a person
that does want to move the window to just add their coordinates to the
--geometry command so there's no reason to continue to force this
behavior since it is less flexible.
Instead, move the window centering stuff out of m_geometry_apply into
vo_calc_window_geometry. We give the power to the caller to whether or
not to force centering the window here and all usage of the function is
updated to simply call it with false for now. Additionally,
--force-window-position being set will also center the window like
before. All that is left is for the windowing code to take advantage of
this. See subsequent commits.
There's really no reason to have all these extra variants. It's not like
this is public API. Collapse it all into one vo_calc_window_geometry
function and callers can simply just pass the appropriate parameters to
get the same behavior as before. I'm about to edit this function again
in a future commit and I really don't want to make a
vo_calc_window_geometry4 for this so let's clean it up.
by default utilises the color space of the screen on which the window is
located. if a specific value is defined, it will instead be utilised.
depending on the chosen color space the macOS EDR (HDR) support is
activated and that OS's transformation (tone mapping) is used.
Fixes#7341
the Screen property localizedName returns a none unique dynamic name
that doesn't allow a specific selection of a Screen on every OS boot.
the name consists of the vendor name and model name (eg DELL U2723QE).
if the same model display is connected to the system several times,
macOS starts to add numbers to the localizedName (eg DELL U2723QE (1)),
that may not be associated to the same Screen on every OS boot or
connecting the display. it also changes the name of the first connected
display by adding that numeration. this makes it impossible specify the
proper screen with the screen-name option every time.
to circumvent this we remove the enumeration from the name and instead
add the serial number to the display-names property. this makes the
actual Screen unique and none dynamic. furthermore the selection of a
screen by name will check for equality for the old localizedName, simple
name without enumeration, serial number and the combined name with
serial number. this makes it possible to select the screen by either of
those names and identifiers, and keeps backwards compatibility with the
old behaviour.
Examples:
localized name (System Settings name): DELL U2723QE, DELL U2723QE (1)
simple name: DELL U2723QE
serial number: 123456789
combined name: DELL U2723QE (123456789)
this will prevent jumping of the window size in the case the window size
was 'externally' modified and not via the window-scale property, when
using the pinch gesture.
Fixes#11594Fixes#13799
the unfsContentFrame wasn't updated when externally resized leading to
a wrong unfs window size afterwards. update it on windowDidResize event
when not in fs, not animating and not live resizing.
this broke with the recent refactor of the input handling. one of the
edge cases was not considered, where not every mouse down event has a
corresponding mouse up event, eg all double clicks or more only have one
up event after the first down event.
this was handled correctly previously.
Fixes#13777
replaces the old focus-on-open option with a more generic focus-on
options that can be extended.
adjust the only platform that uses that option.
Fixes#8337
the render size cached in ctx->vo->dwidth/dheight can be outdated in
some circumstances at the time the context needs resizing. instead use
the current render size.
MoltenVK itself tries to work around a supposedly Metal problem that
itself causes flicker, black screens or broken rendering. it sets the
drawableSize to 1x1 to forcefully complete the presentation. though if
1x1 resolution frame is presented it causes a visual flicker or rather
a solid coloured frame. it causes even more problems since sometimes it
does not reset the drawableSize to the proper resolution and keeps
rendering everything in 1x1.
work around this workaround by discarding drawableSize that are <=1 in
any direction.
Fixes#13505
initially we drew on a dedicated render queue to circumvent certain
bottlenecks on the main queue, like concurrent events that could lead
to late drawing.
though due to the way cocoa works we need to draw an the main queue
otherwise we get undefined behaviour that could lead to crashes.
Fixes#10276
usually the content scale updates automatically, though on init it is
possible the wrong scale is used for the initial rendering leading to a
wrongly sized surface.
properly set the initial content scale of the layer.
this fixes a crash on quit, when a CATransaction from a system owned
thread/event is happening at the same time. locking the context
synchronises these access and prevents the race condition.
the draw operation induced by any display call from the CAOpenGLLayer
doesn't need that lock, since the display function already does lock
that current context.
Fixes#11681