- Mar 26, 2025
-
-
Sam James authored
-
Alexandre Janniaux authored
This patch adds a new metric to track and understand the behaviour of the input pacing done from the input buffering values. The behaviour is showing correct properties currently, but as will be shown later in this commit message, this metric helps debugging pacing issues leading to screen freeze. In the work for making clock-start distributed across every clock tracker, and because of a change removing the call to the function input_clock_ChangeSystemOrigin, the input clock wake-up delay was not computed correctly. Specifically, a huge delay of multiple hundred of millisecond was appearing at the startup of the playback for file:// media, leading to a huge gap in playback. The problem can be revealed when tracing the input_clock_GetWakeup values. Those values are used to pace the input, and they are dates matching with up until when the input is allowed to sleep, or 0 to disable sleeping altogether. The value returned is valid up until vlc_tick_now() is bigger or a new input_clock_Update() is made. By substracting vlc_tick_now() to this date when the value is not 0, we can get the time the input is supposed to wait before doing anything else. The graph would typically look like this when the freeze was happening at the beginning of the playback Input clock wake up ^ 330ms -| +----+ | | | | | | 0 -| ------------+ +--------.. +----------------------------->t In the current state or after proper fixes for the input pacing were done, it would display the following graph: Input clock wake up ^ | +----------------------------->t 0 -| ------------++-------------- | || | || -550ms -| ++ As such, a very high value looks suspiciously wrong, and improvement could be made later to start the wake-up delay at -pts_delay immediately instead of returning 0 as long as the reference point is not registered yet in the input clock buffering subsystem. This metric also catches additional artifacts that are generated by the input decoder waits right at the end of buffering, which might be interesting to investigate later. -
Alexandre Janniaux authored
-
Alexandre Janniaux authored
Just like it's done for projection_mode, setup a state so that changing the stereo mode can be asynchronously done when the rendering loop is ready to provide the OpenGL context.
-
Alexandre Janniaux authored
-
Alexandre Janniaux authored
The first projection state will be needed when changing the stereo-mode in future commits.
-
Alexandre Janniaux authored
Create a dedicated function to restart the renderer given a set of parameters. The function will also be used to change the video-stereo-mode value in the renderer.
-
Alexandre Janniaux authored
The video-stereo-mode is setup the same way I did the projection mode. The client needs to restart the renderer to re-compile the shaders and re-setup the variables for the mode, avoiding the need for a specific API. This is justified by changing video-stereo-mode not happening at each frame. Note that projection_mode is temporarily enforced to PROJECTION_MODE_RECTANGULAR whenever the multiview_mode is enforced to another value than the source, to avoid trying to change the projection from a texture containing the two eyes, leading to weird behaviour. This happens when setting the SIDE_BY_SIDE stereoscopic mode which is made for showing the two frames, but also in the STEREO stereoscopic mode which is not yet supported in the module (need vlc-vr work).
-
Alexandre Janniaux authored
The MAX value allows checking whether the provided stereoscopic value is valid or not.
-
Currently there are two issues here, one hiding the other: - The sed pattern is wrong, causing it to not match due to leading spaces. - The replacement for the second sed pattern is wrong, not removing the @LIBICONV@, causing it to be present in the generated .pc, but due to the previous issue, this was hidden as the iconv detection was never actually removed. This issue only rarely manifested, as we also build iconv in contribs, so it was totally depending on build order if this caused any issue or not.
-
Fixes a build issue related to pkg-config paths: checking for pkg-config... /Users/user/Projects/VideoLAN/vlc/extras/tools/build/bin/pkg-config checking for /Users/user/Projects/VideoLAN/vlc/extras/tools/build/bin/pkg-config library directory... checking for search-list... checking for first directory... none checking if we should install .pc files for /Users/user/Projects/VideoLAN/vlc/extras/tools/build/bin/pkg-config... yes configure: error: expected a pathname, not ""
-
- Mar 25, 2025
-
-
-
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.
-
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).
-
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.
-
- Mar 24, 2025
-
-
- 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.
-
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
-
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`.
-
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).
-
-
-
-
Register the modules into the buildsystem while keeping the dependencies being initialized conditionally, so they can be referenced elsewhere.
-
The libraries are used on modules in other files, and gets undefined on non-windows platforms.
-
- 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.
-
-
-
It should be acceptable to not have background rectangle with non-RHI graphics backend (no shader support).
-
-
-
It should be acceptable to not have background rectangle with non-RHI graphics backend (no shader support).
-
It should be acceptable to not have background rectangle with non-RHI graphics backend (no shader support).
-
-
-
Currently only `CompositorDirectComposition` does graceful exit on scene graph error.
-
-
Startup time is defined as the time it takes to start playing the initial item when the application is opened. Currently probing is done synchronously each time the interface starts. This is not ideal, as we don't expect the system to suddenly start supporting a particular graphics api. Obviously, due to hardware change or driver update or any reason this may change, so we still need to check that each time. In this case, the worst can happen is that `QQuickWindow` emits error and terminates the application (usually with an error message box) when the api is no longer supported. However, since the cached api is checked each time asynchronously, the next startup would be fine. This basically improves the startup performance, at the expense of causing an error and terminating the application (in the worst case) if the system suddenly starts not supporting once valid api. The worst case is a rare case, so I believe that this would be a good optimization.
-
-
-
-
