Claudio Cambra authored 5 months ago and Steve Lhomme committed 5 months ago

macosx: Remove subviews from home view stack view when deallocating the home view stack view controller

Turns out when switching views and deallocating the home view stack view
controller we were not emptying out the subviews for the actual stack
view, which had a reference held on it by the library window.

This means the created containers would stay alive and included in the
home view stack view's subviews... Then when switching back to the home
view we'd initialise a new home view stack view controller, which would
initialise new containers, and then add them to the home view stack
view, creating duplicates

Signed-off-by: Claudio Cambra <developer@claudiocambra.com>

Fatih Uzunoğlu authored 6 months ago and Steve Lhomme committed 5 months ago

When `m_setupStateCond.wait()` is called, the scene graph has already started
to initialize itself. So, 2.5 seconds waiting time was considered to be fair.

2.5 seconds were enough for Nvidia and VirtualBox drivers. However, it turns
out that AMD needs more time.

This is mainly relevant when the application starts with a video.

Fatih Uzunoğlu authored 5 months ago and Steve Lhomme committed 5 months ago

... as it may be necessary by the application,
particularly for the window inhibit case.

Fatih Uzunoğlu authored 5 months ago and Steve Lhomme committed 5 months ago

When scene graph encounters an error, we are already past the latest stage where
recovery is possible. The interface remains nonfunctional in this case, thus the
application must be terminated. This is already done by Qt itself when the signal
is not connected, but in this case we connect to the signal to let the waiting
video thread continue and to print the error.

Note that "If a signal is connected to several slots, the slots are activated in
the same order in which the connections were made". So, in this case exit is going
to be called after the error is printed, which is the intended behavior.

Fatih Uzunoğlu authored 5 months ago and Steve Lhomme committed 5 months ago

The hollow shader discards the pixels that are in the interior area. It
is known that branching in fragment shader should be avoided if possible.

By checking if the window is opaque, we can disable hollowing and use it
only if the window is translucent or transparent (due to window backdrop
blur effect).

The glow effect should not act as a filter for the window backdrop blur,
it is only used for providing a glow effect around the edges. This was
the reason of coming up with the possibility of hollowing.

Currently, areas of the interface that want to show the window backdrop
effect use a hack to "punch a hole" as they are placed deep down in
the scene graph hierarchy and in certain cases parent item(s) provide
background color.

This hack is done by simply disabling blending but still painting with
translucent colors (see `ViewBlockingRectangle`). In this case, it does
not really matter if the glow effect here is hollow or not, because the
areas that want to pass the backdrop effect disabling blending means that
the glow effect would not be visible behind those areas anyway.

However, "punching hole" hack has been used as a convenience when it is
necessary. In the future, the areas that want to pass the backdrop effect
should placed in the scene graph hierarchy so that there is no item in
beneath that is opaque. This is possibly impossible for the PIP player,
but there are currently places in the interface that this can be done,
such as the top bar. So, for these cases, we need hollowing so that the
glow effect does not appear (and act as a filter) in the interface main
area.

We already build Win64 with gcc and Win32 with LLVM.
This is redundant to test the code is building in the target and with the compiler.
There's also the UWP target that uses LLVM with the Win64 code.

We only need the nightly build which will only rebuild contribs when necessary.

The JNI part is not involved anymore. It only builds libvlc.so.

Thomas Guillem authored 5 months ago and Steve Lhomme committed 5 months ago

version is at offset 26

It was not crashing because the stream-filter/access/extractor was
likely reading more than 7.

Thomas Guillem authored 5 months ago and Steve Lhomme committed 5 months ago

Currently, all rtp modules use it but this ops is not mandatory.

Johannes Kauffmann authored 5 months ago and Steve Lhomme committed 5 months ago

No functional changes.

Tested with -O0 with LLVM-mingw for win64 and win32.
It builds fine and uses the assembler code properly.

As in autotools.

We should use the same packing as libdvdread. It's done and made public through
a header. But we must also use the compiler the same way. libdvdread doesn't
force -mno-ms-bitfields.

It's on by default, so not needed in configure.sh.

- the ssp option has been added in 6b1f7dc2
- the pdb enabling is done outside of meson

Fatih Uzunoğlu authored 5 months ago and Steve Lhomme committed 5 months ago

until the drop operation finishes

Fatih Uzunoğlu authored 5 months ago and Steve Lhomme committed 5 months ago

until the drop operation finishes

No need to do some DLL loading/GetProcAddress.
The installer is for Windows XP+ (and Windows 7 on VLC4). So these API's
are always present.

Alexandre Janniaux authored 5 months ago and Steve Lhomme committed 5 months ago

The code will be moved towards a real OpenGL provider module in the
future. This commit starts writing the module like so by ensuring there
is a valid OpenGL startup function for the module.

Currently, the usage of the vout_display prevents from allocating the
views and everything from within the OpenOpenGL function, but they'll
get moved in later patches which will include setting up dedicated
callbacks for the rendering.

Alexandre Janniaux authored 5 months ago and Steve Lhomme committed 5 months ago

No functional changes.

Alexandre Janniaux authored 5 months ago and Steve Lhomme committed 5 months ago

...and use designated initializers to ensure the fields are correct.
This will allow removing the forward declarations.