Modules like glwin32 were still existing solely for the usage of the
win32 sensors code, which was integrated deeply into the win32 display
modules.

By moving it to a vlc_gyroscope module, we can address this and finally
remove the win32-specific integration.

The "sensors" module provides a live viewpoint when using an Android
device. Enabling it will typically override the viewpoint defined by the
hotkey module in the outputs.

The wrapper will allow performing fusion between interface-provided
devices like hotkeys (mouse/touchscreen/keyboard input) and physical
gyroscope sensors like android_sensors, allowing to perform both touch
and physical rotation.

The goal is not to merge both rotations regardless of their axis, but
instead provide sync between an initial position, the sensor value, and
still allow changing yaw during sensors usage.

The API is a bit simplistic for now, but it allows refactoring the
gyroscopic code out of the display plugins, in particular to remove the
specific glwin32.c code for Windows.

It's inspired from original Adrien's viewpoint provider work.

Co-authored-by: Adrien Maglo <magsoft@videolan.org>

Fatih Uzunoğlu authored 1 month ago and Felix Paul Kühne committed 4 weeks ago

I have KWin X11 and the window does not receive expose event
when the window is exposed. This seems to be the reason why
the video freezes after the window gets minimized.

Fatih Uzunoğlu authored 1 month ago and Felix Paul Kühne committed 4 weeks ago

qt: make context current before calling `::createFbo()` and `::destroyFbo()` in `CompositorX11UISurface`

The reason these methods don't make the context current themselves is because
they are called together in `resizeFbo()` where the context is already made
current. This makes it possible to make current once instead of twice (with
accompanying done current in these methods).

Fatih Uzunoğlu authored 1 month ago and Felix Paul Kühne committed 4 weeks ago

Rather than having an assertion regarding the context became current,
we can simply early return in these functions. If the context could
not be made current, it is likely that we are in some sort of
transitional phase and `resizeFbo()` would be called later when the
state is stable either directly or indirectly.

`render()`, on the other is periodically called anyway. It should
be fine to simply return early instead of triggering assertion
failure. When the context can be made current, it can do its job.

Fatih Uzunoğlu authored 1 month ago and Felix Paul Kühne committed 4 weeks ago

- Since hiding the window destroys the wl_surface (before Qt 6.9), this causes
crash on Wayland (adjustments after video window setup is complete).
- With `CompositorX11`, adjusting a flag (such as always on top) and then
(immediately after) toggling the visibility of a window breaks the window. This
is a problem when, for example always on top and client side decorations change
together.

Although it is stated that "some window managers don't like to change frame
window hint on visible window", I have not observed an adverse behavior on X11
(Qt 6.2 and Qt 6.8), and Wayland (Qt 6.8) with KWin X11/Wayland 6.3.1. If this
is a problem of a certain window manager, the workaround should be only done
for that window manager and not in all cases.

At the same time, Qt does not seem to state that adjusting `Qt::FramelessWindowHint`
needs to be done when the window is hidden. So I believe that this should be
safe to proceed.

Fatih Uzunoğlu authored 1 month ago and Felix Paul Kühne committed 4 weeks ago

Imperatively assigning the model is problematic here, because
the model may be accessed before it is assigned.

With declarative approach, it is the QML engine's responsibility
make sure the model is assigned at appropriate time before it
is accessed.

Qt documentation states that [1]:

> If a parent is not provided to createObject(), a reference to the
> returned object must be held so that it is not destroyed by the
> garbage collector. This is true regardless of whether Item::parent
> is set afterwards, because setting the Item parent does not change
> object ownership. Only the graphical parent is changed.

Since the old model is no longer referenced anymore after
`MainCtx.grouping` changes, this approach should be fine.

I have tested this on both Qt 6.2 and 6.8.

[1] https://doc.qt.io/qt-6/qml-qtqml-component.html#createObject-method

Fatih Uzunoğlu authored 1 month ago and Steve Lhomme committed 4 weeks ago

This is useful when `QSGTextureView` is used as the source
of a `ShaderEffect` that does not support atlas textures.

Notable examples are `FastBlur` and `MultiEffect`.

Fatih Uzunoğlu authored 1 month ago and Steve Lhomme committed 4 weeks ago

This reverts commit 2baca715.

Unfortunately it turns out that "They support atlas/sub textures" is not fully
correct. I made that assumption after taking a look at the shader code, and I
concluded that they simply did not bother setting `supportsAtlasTextures` to
`true` from its default value `false` due to negligence because the shader
code that samples the source texture primarily uses the coordinate Qt supplies
(`qt_MultiTexCoord0`) where it already takes the atlas textures into account.

ShaderEffect's documentation states that:

> If supportsAtlasTextures is true, coordinates will be based on position in
> the atlas instead.

Therefore, the coordinates supplied can be used as is with atlas textures. In
fact, we (and Qt) are already doing this in various places (`vec4 texel =
texture(source, qt_TexCoord0)`).

The blur effect shaders uses the same (pre-adjusted) coordinate for sampling
the texture. So, I thought that setting `supportsAtlasTextures` would not have
a negative impact.

However, due to the way Qt does blurring, this pre-adjusted (atlas) coordinate
is offsetted and that offset is obviously specific to the blur effect and not
pre-adjusted for the atlas texture (as Qt does with `ShaderEffect`) since
they never claim to support atlas textures in blur effect, they don't bother
normalizing the offset coordinate according to the atlas.

Unfortunately, this means that atlas textures must be detached from the atlas,
incurring a copy, to be used as a source for the blur effect. This is not a
big problem for us, because most of the places where we use the blur effect
already have the source textures independent (not in the atlas). And we still
benefit from `QSGTextureView` that it prevents incurring a copy when the source
texture is not in the atlas.

- Main view (for mini player frosted glass effect background) is an item
layer (not to mention a dynamic texture). They are never put in the atlas.
- Player background uses mipmap, currently Qt does not support mipmapped
atlas textures, so all mipmapped textures are independent textures. We use
mipmapping here not to prevent this issue, but we actually benefit from
mipmapping in this case as we do fluent size change based on window size.
- Music artist header background, depending on the atlas size, may be put
in the atlas. This currently depends on the initial window size, if it is
small, the texture is not put in the atlas and blurring works fine. This
is because currently Qt determines the atlas size based on the initial
window size (I guess this is from the times when they primarily targeted
mobile platforms with Qt Quick, back in 2010s).

Unfortunately `QQuickImage` (`Image`) does not have a parameter to disable
putting textures in the atlas. Setting `mipmap` as done in player would
be fine, but we don't want/need mipmapping in music artist view. This does
not mean much anyway, as with the revert here the shader effect would ask
the texture to "remove" itself from the atlas (by copying, as per the default
RHI atlas texture implementation), so blurring starts working fine.

This change brings an additional requirement, although not used currently,
if a target of `QSGTextureView` is in the atlas, and the texture view is
used as source for blur effect, the request of detaching from the atlas
texture (`QSGTexture::removedFromAtlas()`) would fail. The next commit
makes sure that `::removedFromAtlas()` works fine with `QSGTextureView`,
too, even though currently it is not used (I used a trick to disable
layering instead of using `QSGTextureView` in music artist header).

Fatih Uzunoğlu authored 1 month ago and Steve Lhomme committed 4 weeks ago

This reverts commit edb16056.

This became obsolete when we got rid of transitions (89fe5f60).

Alexandre Janniaux authored 1 year ago and Steve Lhomme committed 4 weeks ago

Register the modules into the buildsystem while keeping the dependencies
being initialized conditionally, so they can be referenced elsewhere.

Alexandre Janniaux authored 2 months ago and Steve Lhomme committed 4 weeks ago

The libraries are used on modules in other files, and gets undefined on
non-windows platforms.

Fatih Uzunoğlu authored 1 month ago and Steve Lhomme committed 4 weeks ago

- Use root size for the shader if image is not available, as in
  that case the image would not have a sensible size. The implicit
  size is chosen arbitrarily to be 64x64 instead of 0x0, which
  is mainly relevant when root does not have an overridden size.
- Do not bother calculating the crop rate if there is no image.
- Do not do outlining if there is no image, as in that case it
  means there is nothing to outline.

This ensures that background is shown while the image is loading.

`ShaderEffect` uses a transparent dummy texture with repeat wrap
mode when the texture is not available. With source over blending
of the texture into the background, a fully transparent source
yields the destination color, which is the background color.

Fatih Uzunoğlu authored 2 months ago and Steve Lhomme committed 4 weeks ago

It should be acceptable to not have background rectangle
with non-RHI graphics backend (no shader support).